Diagnositic and treatmetnt tool and method for electronic recording and indexing patient encounters for allowing instant search of patient history

ABSTRACT

Device and method for improved diagnostic and treatment of patients. Clinician&#39;s notes of diagnosis, treatment or testing are electronically recorded thereby becoming an entry in a patient specific EHR. Coding appropriate to diagnosis etc., may be adapted by the clinician and the coding integrated into the EHR entry. The EHR may be searched using adapted codes as an index of diagnosis, treatment and testing. The tool and method includes program for facilitating entry of clinician notes (auto complete and autocorrection) and suggestion of appropriate code entries correlated to the content of the clinician notes. The program may include authentication protocols for protecting privacy and accesses to patient EHR. Code and code descriptors may be the product of established protocols such as CBD-10 or CPT. The tool and method may allow immediate search of patient&#39;s EHR for prior relevant conditions or treatment thereby facilitating prompt treatment of underlying cause of malady.

RELATED APPLICATIONS

This application claims priority to provisional application Ser. No.62/714,845, entitled “INDEXING OF MEDICAL RECORDS UTILIZING CODINGPROTOCOLS” and filed Aug. 6, 2018, said application is incorporatedherein by reference in its entirety. This application also claimspriority to provisional application Ser. No. 62/728,756, entitled“INDEXING OF MEDICAL RECORDS UTILIZING CODING PROTOCOLS” and filed Sep.8, 2018 and said application is also incorporated herein by reference inits entirety. Further, this application claims priority to provisionalapplication Ser. No. 62/750,300 entitled “INDEXING OF MEDICAL RECORDSUTILIZING CODING PROTOCOLS” filed Oct. 25, 2018, said application beingincorporated herein by reference in its entirety.

FIELD OF USE

This disclosure pertains to electronic recording of clinician notes ofpatient encounters, thereby creating patient electronic health records(EHR) that are contemporaneously indexed utilizing one or morealphanumeric code protocols wherein the protocols may be the sameutilized for achieving reimbursement of medical services from thirdparty payors. EHR records incorporating coding protocols may beinstantly searched utilizing the coding as an index. Instant access torelevant portions of a patient history facilitate accurate diagnosis andinitiation of treatment and testing. Protocols include the InternationalClassification of Diseases (ICD) and the Current Procedural Terminology(CPT). This disclosure also pertains to conducting searches of patientspecific electronic health records utilizing one or more indexingalphanumeric code protocols. Also included in the disclosure is a systemincluding a device for electronically entering patient identifyinginformation, diagnostic information or symptoms, other medicalinformation pertaining to tests or treatments and entering appropriatecodes from a selected protocol correlated to the information. Theinformation can be transmitted electronically to a repository of EHRrecords. The device may allow initiation of the repository searching itsrecords and transmitting the search results to the device or otherdisplay or storage mechanism.

It will be appreciated that without access to a patient's medicalhistory, the clinician may only treat the observed symptoms in contrastto the underlying problem or cause.

RELATED PRIOR ART

A medical health care provider creates a record of patient diagnosis andtreatment. The record is individualized by patient. The medical recordsare patient specific. These records may be hand written and unindexed(other than perhaps by chronological order).

It is difficult for a subsequent medical health care provider to rapidlyobtain access to the patient's records of earlier test, treatments ordiagnosis that were conducted by earlier health care provides. Requestsrequire the patient's written consent and this consent must be providedto the earlier health care provider before there can be any release ofpatient records.

A patient's records of earlier treatment, testing and diagnosis may bein a variety of locations. The patient may have a limited recollectionof the prior medical health care providers and have no contactinformation.

Records that are received are often copies of paper records withmultiple handwritten notations that may be difficult to timely decipher.Much of the paper records that are received may be unrelated to theexisting medical event and therefore be of little or no value to thesubsequent/requesting medical health care provider.

Also a patient's medical record may be stored or recorded on anelectronic format. (The patient's electronic medical record is termed anEMR.) The records may be in a format that does not easily allow the EMRto be searched for particular topics. It may be necessary to attempt toconvert some or all of the EMR files to an electronic format compatibleto the format of the requesting medical health care provider. The EMR isin an electronic format and identifies the patient and the date thatservice was provided. The EMR is intended to be the electronicequivalent of the paper records.

The EMR records include the description of the patient, the symptoms,the diagnosis and treatment. The EMR records may be specific to eachhealth care provider, e.g., physicians, laboratories, etc., or healthcare facility, e.g., clinic or hospital, etc. The records may be paperor recorded in one of multiple electronic media. As stated above, themedia may be incompatible with the system or format utilized by therequesting entity (subsequent medical health care provider). The recordsare seldom, if ever, effectively indexed by date, medical event ortests/procedures.

All of these limitations make timely receipt of relevant past medicaltreatment and testing to be very problematic. Although the prior recordsmay be retained in an electronic format, there are very significantissues of compatibility of formats and an inability to perform searches,e.g. word search of the records. According it is necessary to parse thereceived records similar to that required of paper records. The resultis that the patient EMR records may not be readily communicated outsideof an individual hospital or physician's office.

The above described current medical practice of maintained medicalrecords, often relying on paper records or variously maintained EMRformats at disparate locations, can be voluminous. Accessing the pasthealth care records is a time consuming matter and may not be effectivein attempting to provide best care to the patient in real time. It willbe appreciated that this problem may be especially acute in emergencycare situation.

There has been increasing emphasis to maintain the patient health carerecords in an electronic format. This would shrink the storage burden ofmaintaining archives of voluminous patient paper files. It has thepotential to also speed the retrieval of past information for thebenefit of the current health care provider and patient.

There also has been considerable effort to document patient diagnosis,treatment and testing using a common protocol of descriptors. Severalattempted comprehensive protocols have been developed to standardizepatient histories. These standard protocols utilize alphanumeric codingschemes wherein different diagnosis have separate codes. Similarly,different treatment procedure have individualized alphanumeric codes.Also test and laboratory testing procedures are included in these codingprotocols. There complexity of medicine and the tremendous variety ofaliments and diseases has required these coding protocols to incorporatetens of thousands of separate codes.

This coding effort has been adopted by third party payors such as healthinsurance companies, Medicare and Medicaid in an attempt to standardizereimbursement for procedure, understanding that the multiple health careproviders use different terminology to describe the same or comparableservices. However due to the great number of codes that can be assignedand the vast number of procedures and diagnosis, it has been necessaryto create a class of coders to review medical records of treatment andassign the appropriate codes. Obtaining consistency and accuracy is asignificant task.

There is also the factor of facilitating the sharing of patient medicalinformation while maintaining patient privacy. The Health InsurancePortability and Accountability Act of 1996 (“HIPAA”) imposes controlsfor privacy protection. This includes a requirement that the patientconsent to any disclosure of information.

BRIEF SUMMARY OF DISCLOSURE

Electronic health records (EHR) are understood to contain all of theinformation recorded in paper records and charts or contained in EMR,plus the EHR are designed to collect all medical information from allhealthcare sources, including multiple physicians, hospitals, and thepatient themselves.

In addition to providing a record of patient care, including diagnoses,procedures/treatments and test results, the medical health careprovider's records, either maintained in paper or electronic format, areused to generate invoices for submission to the patient or a third-partypayor, typically an insurance provider. The records of the individualhospital or medical service provider may be termed “patient medicalrecords” (PMR). If maintained electronically, the records may bedesignated EMR.

To facilitate payment of medical invoices by third party payors, i.e.,typically health insurance companies, the medical services are convertedor indexed to a uniform coding scheme or protocol (hereinafter “codingprotocol”). There are differing systems. Medical service codingprotocols subject of this disclosure include but are not limited to theInternational Classification of Diseases (ICD) and the CurrentProcedural Terminology (CPT).

In current practice, the PMR created by the physician or other serviceprovider may be reviewed by a medical billing coder. The medical billingcoder (residing as an employee or contractor of the medical serviceprovider) assigns alpha-numeric codes consistent with diagnosis,treatment, procedures or testing. The coding is in accordance with oneof the several medical coding protocol or coding scheme. The codingprotocol may include procedures for oversight and review of the accuracyof the coding assignments to the health care provider's PMR or EMR. Thecoding information may be submitted for review, approval and payment bya third party payor. Creation of the medical record coding is separatefrom the creation of the patient's medical health care record. Thecoding information is not retained as part of the patient's PMR or EHR.

SUMMARY OF DISCLOSURE

The teachings of this disclosure include a diagnostic and treatment toolthat allows electronic recording of initial or subsequent patientencounters wherein the clinician notes may be recorded with appropriateand accepted coding protocols. The combined diagnostic and treatmentnotes, containing such codes, create a more complete patient specificEHR. This more robust EHR may be used to electronically search thepatient's history to corroborate or assist in diagnosis and treatment.With instant access to the relevant portions of the patient's history,the clinician can treat the cause of the patient's malady in contrast tomerely responding to observed symptoms.

The device or tool of this disclosure, by providing instant access tothe relevant portions of the patient's history may confirm theclinician's initial diagnosis, thereby expediting the start oftreatment, and avoiding delay waiting for lengthy (and costly) testresults.

This disclosure teaches integrating established and accepted codeprotocols used to categorize diagnoses, treatments and tests for billingof third party payors with the specific medical information orapplicable portions of the patient's electronic health record (EHR). Oneprincipal code, Current Procedural Terminology (CPT) has been developedin the U.S. by the American Medical Association. Another medical codingprotocol widely used in the International Classification of Diseases(ICD) code protocol development by the World Intellectual PropertyOrganization (WIPO). The current version of the ICD protocol is ICD-10and contains over 50,000 entries.

This disclosure also teaches components or devices that allow healthcare providers (elsewhere termed “clinicians”) to electronically enterdata of patient encounters, such as identity, symptoms, diagnosis ortreatment. In response to the data entry, the device may displaysuggested code protocol entries appropriate to the entered data, e.g.,symptoms or diagnosis. The suggested codes may be adopted by the healthcare provider. The codes may then be added to the entry of medical dataas part of the EHR.

This disclosure includes expanding patient electronic health records(EHR) stored or recorded by physicians, hospitals, clinics,laboratories, etc., (hereinafter “health care providers”) to incorporateindustry coding protocols correlating the EHR described diagnosis,treatment or service. It is appreciated that these coding protocols areused to facilitate payment to the health care providers from third partypayors, i.e., health insurance companies, Medicare and Medicaid.

A health care provider's steps to enter a patient diagnosis, etc., mayalso create the coding needed for submission of an acceptable invoice tothe third party payor. The coding protocol can also contained textdescriptor that will appear on the invoice and provide usefulinformation to the patient.

The expanded use of such coding protocols as taught by this disclosurewill also facilitate the ability of health care providers to search andaccess patient histories from patient EHRs. The coding, now incorporatedinto the patient specific EHR as taught by this disclosure, will providean index to search the EHR for similar past diagnoses or treatments. Amedical health care provider can request patient specific informationutilizing the appropriate code or codes to extract the relevant EHRrecords without having to parse through a voluminous totality of healthcare records, much of which may not be relevant to the instant medicalevent.

Accordingly, in one embodiment of the disclosure, the treatingphysician, e.g., emergency room doctor, may be able to quickly learn ofthe patient's relevant medical history by “key word” or code searchingof the patient's EHR.

The disclosure also teaches a method of expeditiously and reliablyassigning relevant coding protocols at the time a health care providermay be entering patient examination notes, surgery or proceduresummaries, etc. It will be appreciated that the number of accepted andmaintained code sets may exceed 50,000 codes with individual codedescriptors. This makes current bill coding practices for searching forthe correct code tedious and time consuming for both the medical coderor the medical health care provider. This also results in mistakes,delays, incorrect payment, etc. This disclosure may reduce these issues.

It will be appreciated that often current practice for medical coding isthat medical codes are subsequently and separately added after thepatient encounter or treatment. The code entry is often performed bymedical billing coders who are not trained health care providers. Thissequence and practice results in numerous incorrect code entries,causing numerous billing errors, payment delays and over/under payment.

Similarly, this difficulty may exist when the code protocols are used toindex and identify diagnosis, treatment and test results that may berelied upon by other (subsequent) medical health care providers.Accordingly, the disclosure also teaches a method of auto identificationand suggestion of applicable/relevant codes at the time the examinationnotes, etc. are created. The codes provide an alpha numeric sequence(currently up to 7 characters in length) combined with a briefdescription of the medical diagnosis, procedure or test, i.e., textdescriptor.

The disclosure therefore also teaches devices such as electronictablets, e.g., iPad, or smart phones programed to accept entry ofmedical data and suggest and display one or more code protocol entriesfor possible adoption by the health care provider for adoption into theEHR as well as for medical expense reimbursement. Also the device,having received medical code entries from the health care provider, maybe used as a platform to initiate a search of the applicable patient'sEHR for similar past medical events, thereby allowing the health careprovider to receive the patient's medical history in real time. Thedisclosure includes utilization of the device, e.g., display screen ofthe tablet, smart phone, etc., to convey the patient's medical historyas search results.

For example, if the patient exhibits symptoms of a knee injury, thecurrent ICD-10 codes S83.4 and S83.5 may be displayed along with thetext descriptor to the clinician. If deemed appropriate, the codes maybe adopted in the patient's EHR. Also an electronic search may beinitiated via the device. Entry of these codes would return all recordsof sprains of the cruciate ligament of a knee and sprains of collateralligament of a knee. Entry of code S83.20 will provide information ofpast diagnosis of tears of a meniscus of the patient's knee. Note thatspecifying the 4 character codes will return entries of all underlyingcodes, i.e., entry of code S83.4 will also return an entry of S83.41.

The disclosure teaches a system for improving the efficiency andreliability of entering correct codes for each diagnosis, treatment ortest by a coding protocol or program that auto suggests coding entriesin response to the text added by the health care provider creating theEMR. Alternatively, the program may suggest one or more codes based uponthe totality of the health care provider's entry. The coding entries canbe alpha-numeric, alpha or numeric codes contained in a medicalprovider's service code protocol.

The operator (medical coder or medical health care provider) may enter adescription of diagnosis, treatment or testing into a particular dataarea utilizing a key board and entered data may be displayed on theportable device screen. A dynamic list of possible codes is generatedand displayed. The listing is based on entered text for the diagnosis,treatment or testing, etc. In one embodiment, the suggested (orselected) codes may appear within the entered text or in a separatedesignated area. It will be appreciated that the data entry for codingand recording will be performed with a key board and display screen. Forexample, the data entry field may be accompanied by a column, row ormachine fillable block (“code space”) located to the left or right ofthe data entry field. The data entry field and code space may beexpandable to allow unlimited text content. The code space may bedesignated as “code”, or “diagnosis, treatment, test code” or similar.As the medical professional enters text into the data field, possiblecodes may be simultaneously displayed in the designated code space. Asthe diagnosis, etc. is entered, suggested codes may appear in the codespace. The medical professional may select one or several alternatecodes for recording with the EHR.

The suggested code selection may be based upon text entered by thehealth care provider. As the health care provider enters characters oftext data item, the list of corresponding diagnosis, treatment or testcodes are searched for an entry that is appropriate for or matches theentry typed in the data field. If a code match is found, then thematching code (or codes) is displayed in the code space to the healthcare provider as a suggested completion. The health care provider canthen elect to accept the suggested completion or to continue enteringthe data item. The coding may be separately inserted. However thatcoding input will be recorded in the EHR.

The disclosure may also include incorporating an auto correct function.As text is typed or otherwise entered into the data entry field, theprogram may automatically suggest a completed word or entry. The autocorrect function may correct spelling or grammatical errors. The suggestentry may match a text description that accompanies an alpha-numericcode. A code protocol can comprise the alpha-numeric code plus a textdescriptor.

The ICD, CPT or other protocol utilized third party payor coding schemecan be used to provide medical providers with an index that facilitatethe medical heath care provider obtaining timely access into a patient'svoluminous EHR.

This disclosure teaches a system algorithm for classification andindexing of patient electronic health records (EHR). The algorithmutilizes continuously updated code descriptors or code classifierswherein the applicable alphanumeric codes, described in the codeprotocol, are assigned to a patient's electronic health record (EHR)entries. The EHR entries are created by health care providers indescribing or listing diagnoses, treatment procedures and testinginformation. The indexing can facilitate identifying prior healthdiagnoses, treatments and tests for the patient that may be related orrelevant to the patient's current medical event. The index identifiesthe parts of the body that have been affected, the nature of the healthissue, any treatment performed or tests (and test results) that havebeen conducted.

One of the goals of this disclosure is to utilize existing medicalbilling code protocols to provide a ready and consistent index topatient electronic health records (EHR). One manner of accomplishingthis goal is to incorporate the assigned billing codes into the EHR. Thecodes can be embedded into the transcript of the patient's priordiagnosis or used as part of an EHR section header. The incorporatedcode may include the code descriptor. The code descriptor may, in oneembodiment, contained the amendments or annotations created by the priorhealth care provider. The alphanumeric code is intended to be closelyassociated with the relevant and corresponding portions of the EHR entrycreated by the health care professional. Searching the patient's EHR bycode number will lead to the notes, treatment and test results thatpertain to the medical conditions assigned to the specific alphanumericcode.

The disclosure also includes an EHR system wherein the records areannotated with the applicable codes from the protocol. It will beappreciated that such a EHR system will be readily searchable. The EHRsystem and method of creating such system is disclosed and may beaccomplished by the use of the tool and method of use.

In one embodiment, it is the goal that the current health care providercan receive the information of past (and alphanumeric code indexed)medical examination, etc., in real time during, for instance, thecurrent initial examination of the patient. The electronic records canbe electronically recognized, parsed and the responsive portions becommunicated to the requesting health care provider without humanintervention. In an embodiment, the information can be displayed on aclinician's device, e.g., iPad. Again cryptography such as public andprivate keys may be utilized to ensure the authenticity of the receivedrecords. Similarly, cryptography can be used to ensure the requestinghealth care provider is authorized to receive the information extractedfrom the EHR. The validation measures may include block chain technologyto ensure the validity and authenticity of the extract portion of thepatient's EHR.

It is one goal of the disclosure that the current health care providerelectronically record observations of the patient's condition andresulting diagnosis as an entry into the patient's EHR. The electronicinterface device may allow access to a network or system containing thepatient's EHR. The entry may be indexed by the applicable alphanumericcode as well as by date. The alphanumeric codes are assigned toseparately identified medical conditions utilizing recognized industrycoding protocols. For example, it will be possible to learn of treatmentfor knee injury by entering search terms consisting of one or both textentries, e.g., knee pain, knee swelling, etc. or by code entries, e.g.,ICD-10 codes S83.4, S83.5, etc. The EHR can also be search by date,e.g., date of treatment, test or diagnosis, etc.

It is a goal that the health care provider's entry into the EHR becontemporaneous with the health care provider's examination of thepatient. The health care provider's entry of notes or diagnosis mayallow an algorithm to assign one or more codes from an industry acceptedcode protocol at the time the entry is created. The disclosure includesthe algorithm of the system suggesting applicable codes to the healthcare provider based upon the text of the health care provider's notes,etc. The suggestions are to be enhanced by the system algorithm havinglearned the correlation of terms used by the health care provider withthe code protocol.

Therefore the disclosure includes machine learning capabilities whereinthe algorithm associates and integrates past data entries with adoptedcode selections. This will allow subsequent data entries to prompt arevised (and more responsive or applicable) listing of suggested codes.This learning maybe device specific (reflecting data entries and codeselections of an individual clinician) or system wide.

It is yet another goal for the health care provider to be able topromptly request a search of the patient's EHR for similar prior eventsor occurrences. For example, it will be helpful for a physicianexamining and treating a patient complaining of knee pain to know thatthe patient has previously had a surgical procedure to repair a tornmeniscus of his/her knee. For example, the current health care providermay quickly learn whether the complained event is a new injury or anaggravation of an old injury. Further the health care provider may learnof past unsuccessful treatment. This may allow the current diagnosis tobe more accurate and to allow more effective treatment.

Therefore the disclosure teaches an embodiment wherein the health careprovider may initiate a search request, via his/her electronic interfacedevice, of the patient's EHR based upon the codes assigned to thecurrent patient observations or diagnosis. The search request may beinitiated upon the health care provider authenticating his/her authorityfor access to the patient's EHR. The search request may includeprocedures to ensure that any received information is valid andauthenticate. In an embodiment, the health care provider may be able toinitiate the search request without having to leave the deviceelectronic screen displaying the health care provider's currentdiagnosis. Stated differently, the health care provider's draft notesand diagnosis, correlated with a suggested or accepted alphanumericcode(s), may serve as the search request.

Another goal is that the suggested codes include the generic code aswell as the species that may be selected by the health care provider (ormodified by amendment of the code descriptor). For example, a codeindexed diagnosis for pain in knee may include broad generic codes forknee as well as one or more species codes for specific to the healthcare provider's diagnosis. The device subject of this disclosure mayallow the health care provider to tailor a search broadly or narrowly.

It is another goal to provide a system in which the health care providercan only enter his/her notes of observation or diagnosis after thehealth care provider is identified and authenticated as having access tothe patient's EHR. This may be performed by several different steps,including a two factor formulation or authentication procedure. Theadvantage of this embodiment include that user login, i.e., the healthcare provider, utilizes two stages: a first stage, including anonymousauthentication and a second stage, including identifying informationauthentication, in which the user needs to provide a user name andpassword for authentication.

This application pertains to an tool and method for accessing arepository or database of electronic health records, i.e., EHR records.This application also pertains to a repository of electronic healthcarerecords that may be accessed electronically the and electronicallystored health care records (EHR) of individually identified patientssearched for specific terms or medical conditions, diagnoses, medicalprocedures or treatment, or testing such as laboratory tests, imaging,etc.

The EHR records of multiple patients may be collectively stored in anEHR repository. The records may be searched by individual patient nameor other identifiers such as but not limited to patient name, date ofbirth (DOB) or social security number (SSN).

Multiple EHR or EMR records for an individual patient may be stored inchronological order.

The EHR records may contain information regarding health events andmedical encounters with health care providers. The EHR records maycontain diagnoses, medical procedures or treatments or laboratory testresults or imaging, e.g., MRI or X-ray. Each entry of diagnosis,procedure or testing may be annotated or accompanied by an alphanumericcode. The code may be correlated to and identify a specific diagnosis,treatment or test procedure.

The application includes a system of components that allows a healthcare provider to (i) identify the patient, (ii) record a draft for finaldiagnosis, (iii) enter procedures or test performed, etc. The recordingcomponents (elsewhere termed “electronic device” or “user device”) canelectronically transmit the recorded patient information to a EHRrepository. The transmitted information may be added to thechronological listing of EHR events. The device can also be used totransmit the information to cause a search to be conducted of earlierrecorded EHR events for possibly related medical treatment or tests.

The EHR records, created by the device for (i) memorializing thediagnosis and treatment of a medical event or (ii) searching past EHRrecords within the repository for related or similar diagnoses,treatments or tests, may include alphanumeric codes correlated to orrepresenting/identifying specific medical diagnosis, treatment ortesting. The prior EHR records may incorporate similar alphanumericcodes. The function of searching the repository for related or similardiagnoses, treatments or tests may utilize the coding protocol foridentifying the diagnoses, treatments or tests.

The search results, incorporating the same or similar alphanumericcodes, may be transmitted to the requesting party having initiated thesearch, thereby allowing a health care provider to learn the patientshistory of medical conditions or treatments. This will also avoidduplicative tests, lost time and waste

The user device subject of this disclosure may be the user devicedescribed in the related applications identified above.

The system also includes the transmitting components such as servers,the Internet, an intranet or internal network, and an EHR repositoryaccessible to the device utilizing communication components. The systemmay also comprise public key infrastructure. The disclosure alsoincludes a method for promptly searching and retrieving medicalhistories for real time use by a health care provider.

BRIEF SUMMARY OF DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of the specification, illustrate preferred embodiments of theinvention. These drawings, together with the general description of theinvention given above and the detailed description of the preferredembodiments given below, serve to explain the principles of theinvention.

FIG. 1 illustrates one embodiment of the patient examination, diagnosisand treatment cycle with designation of applicable ICD codes from thecoding protocol. Included are steps of initiating a search of thepatient's EHR using primary & secondary ICD codes and initiating aninvoice for services utilizing the primary ICD codes.

FIG. 2 illustrates an embodiment wherein the patient is examined and adiagnosis assigned utilizing the ICD coding protocol, including optionalassignment of additional secondary codes that may be relevant to thediagnosis or follow-on treatment. Treatment can be initiatedincorporating ICD or CPT codes with initiation of search and invoicingusing ICD or CPT codes.

FIGS. 3a-3f illustrate one embodiment of a screen display of the devicesubject of this disclosure wherein the provider's (clinician's) entriesare displayed (with auto correct features) and auto or manual filling ofcodes applicable to the provider's text entries. In this example, theclinician's notes are contained on the right hand side of the screendisplay and the suggested codes are displayed in a left hand panel ofthe screen display.

FIGS. 4a & 4 b illustrate a computer and computer environment suitablefor supporting the operation of a device embodiment subject of thedisclosure. FIG. 4c illustrates a flow chart for a autocompletefunction.

FIGS. 5 illustrates the operations of the autocomplete function of thedisclosure and which is incorporated into the display of one embodimentof the device subject of the disclosure.

FIG. 6 is a further illustration of the operation of the autocompletecommand.

FIGS. 7a & 7 b are further illustrations of the operation of theautocomplete command. FIG. 7a expands the description of a stepillustrated in FIGS. 4c and 5. FIG. 7b is an expansion of a stepillustrated in FIG. 7 a.

FIG. 8 illustrates that the autocomplete algorithm using inputparameters. It is an expansion of a step illustrated in FIG. 4 c.

FIG. 9A illustrates an embodiment wherein the contents of a patient'sElectronic Health Records (EHR) can be classified into class andmultiple subclasses, etc., by entry of subject matter utilizing a codingprotocol such as the Classification of Procedural Terminology (CPT).“EHR File Storage/Document Collection” may include a patient EHR ordraft EHR. Also illustrated are user (health care provider)authentication and sign in protocols.

FIG. 9B illustrates an embodiment of a classification system wherein anEHR document is created or retrieved. The document may be presented tothe user and a user coding decision made. Documents or text may also bemachine reviewed for suggested coding into a class or subclass.

FIG. 10 illustrates an embodiment showing a relationship betweenmultiple health care providers (clinicians or users), the user device(including display, processor, storage device and input or interfacedevice) and a network of possible health care entities possessingpatient EHR documents. The network may constitute a distribute networkwherein each entity contains identical copies of a patient EHR.

FIG. 11 illustrates a further relationship between the processor of thehealth care entity possessing EHR documents and the components of theentity storage and user device.

FIG. 12a illustrates an embodiment of the health care provider (user)interfacing with a document manager, including the health care providerinputting text information and presentation of possible/suggested codingdecisions. Also shown is the data entry information for utilizing theinformation presented on the display screen to initiate an optionalsearch function.

FIG. 12b illustrates an alternate embodiment of a display screen on thehealth care provider's (user) device wherein the entered text isdisplayed next to device suggested code responsive to the entered text.Also shown are components to accept or reject the suggested code,submission of the accepted code and selected document notations forentry into the patient EHR. Also shown is a component to initiate asearch of the patient's EHR. The search may utilize the suggested codelist

FIG. 12c illustrates another embodiment wherein the health care providerutilizes the document controls shown in FIG. 12a or 12 b for theinclusion of codes. Also illustrated is the health care provider entryof text, etc., based upon diagnosis, procedures or tests, optionalsearch request to network, etc., review of draft EHR entries andoptional search results. Also illustrated is the coding decisiontransmitted to a document manager and submission of final EHR entry to afile storage data base. Note that the file storage may be a distributednetwork wherein each node of the network possesses an identical copy ofthe patient EHR.

FIGS. 13a through 13g illustrate different embodiments forauthentication of the health care provider to access the patient EHRrecords.

FIG. 13a illustrates a two step health care provider authenticationprotocol.

FIG. 13b illustrates the first step of the two factor authenticationprotocol.

FIG. 13c illustrates detail of the second step of the two factorauthentication protocol.

FIG. 3d illustrates the relationship of the Verification CodeAuthentication Module to the Username and Password AuthenticationModule. FIG. 13e illustrates the relationship of the two factorauthentication protocol and the health care provider user device.

FIGS. 13f & 13 g illustrate a further embodiment of the two factorauthentication protocol.

FIG. 14 illustrates an embodiment of the health care provider enteringtext (patient observations and diagnosis information) to an EHR with thedevice suggesting applicable codes (with code descriptors) and devicelearning modified code descriptors (code identifiers) from accepted textand codes.

FIG. 15a illustrates an embodiment of the steps wherein the health careprovider requests that past EHR entries be searched utilizing theaccepted codes as indexing components with the accepted diagnosis, etc.,text. Illustrated is an embodiment wherein the health care providerselects the entities from whom a search is requested. Also illustratedis an embodiment of the steps for identifying and authenticating therequesting health care provider prior to receiving EHR documents.

FIG. 15b illustrates a more detailed description of steps required inorder to receive EHR extracts matching or relevant to the code indexedrequest.

FIG. 16a illustrates utilization of the QR code.

FIG. 16b illustrates use of the signature encryption and cyphertextauthentication module.

FIGS. 16c & 16 d illustrate extraction steps of the cyphertextencryption module.

FIG. 16e illustrates a flow path utilizing the QR cyphertextmethodology.

FIG. 17 illustrates one embodiment showing the relationship between thehealth care provider's device display, input or interface component andthe information classification system.

FIG. 18 illustrates an embodiment of the steps to request a medicalrecord from an EHR repository. The method includes optional steps forusing a user name and password of a health care provider as well asauthenticating a user device such as a tablet computer, CPU, smartphone, etc. Note this embodiment also includes the health care providersupplying identifying information at the initiation of the process.

FIG. 19 illustrates an embodiment utilizing a PKI infrastructure,including the health care provider transmitting an authorizationcertificate along with a public key at the start of the request processto the EHR repository.

FIG. 20 illustrates an embodiment of a PKI infrastructure.

FIG. 21 illustrates another embodiment of a PKI infrastructure. Includedis the optional Online Certificate Status Protocol, CertificateTransparency Log and Root CA.

FIG. 22 illustrates an embodiment of the components of the system

FIG. 23 illustrates an embodiment of the method subject of thedisclosure

DETAILED DESCRIPTION OF DISCLOSURE

Millions of individuals are examined, diagnosed and treated for medicalissues each year in the United States. Each physician, hospital, clinic,laboratory or medical testing facility (hereinafter “health careprovider”) records the examination, diagnosis and treatment pertainingto an individual patient in either paper or electronic format. Further,most individuals are covered under some form of third party medicalservice payment system, i.e., health insurance, Medicare, Medicaid, etc.In the past, each health care provider submitted invoices forreimbursement to one or more third party medical payment system. Eachhealth care provider utilized their own system for describing commondiagnoses and services.

To simplify the reimbursement process, standardized coding schemes orprotocol have been developed. One principal code, Current ProceduralTerminology (CPT) has been developed in the U.S. by the American MedicalAssociation. This code has developed succinct but detailedclassifications to accurately distinguish among different activities(including differing activities pertaining to the same body part, e.g.,knee or kidney). This medical coding scheme is used invoicing andpayment for medical and health care services. Identical treatments,although described in different terms, are intended to assign the samebilling code. This has numerous benefits, including expediting paymentsto health care providers. For instance, third party payors are able toassess variations in invoices for identical medical treatment service.

Another medical coding protocol widely used in the InternationalClassification of Diseases (ICD) code protocol development by the WorldIntellectual Property Organization (WIPO). The current version of theICD protocol is ICD-10 and contains over 50,000 entries.

Often, the assignment of codes is performed separately from thedocumentation of a patient diagnosis, treatment or test. The code isused to as billing codes. The codes are not routinely part of thepatient's medical record (PMR) or electronic health records (EHR). Thecodes are assigned by trained individuals frequently termed as medicalbilling coders. However, medical billing coders are not trained medicalprofessionals. Coders seek to interpret the notation of diagnosis,treatment and testing created by health care providers and correlate thediagnosis, etc. to the code protocol. A numeric or alpha numeric codingscheme such as the CPT or ICD is used by the medical billing coder.Frequent mistakes or mis-interpretations occur resulting in delayedpayment etc.

The coders endeavor to assign an appropriate code to the diagnosis andtreatment services provided to the patient. Services pertaining to apatient's knee receive different code(s) from the codes assigned fortreatment of an intestinal disorder. Surgical services are codeddifferently that drug therapy. Services such X-ray and laboratory bloodwork are also coded differently. This pre-established coding scheme isintended to be applied uniformly for the same treatment or diagnosis formultiple patients. One or more codes are assigned to each diagnosis ortreatment service provided to the patient. The coding schemes orprotocols provide a uniform basis for time and cost efficient review,approval and payment of medical invoices by third party insuranceproviders. The patient is typically the beneficiary of a healthinsurance contract with the third party payor.

Increasingly, patient medical records (PMR) are retained electronically,frequently termed electronic medical records (EMR).

One aspect of this disclosure is to provide a diagnostic tool to expandthe EMR created by one or several health care providers into a morecomprehensive electronic health record (EHR) by encouraging the commonuse of medical coding schemes or protocol such as CPT that is applied toall patient records created at all (or nearly all) heath care providers.An EMR, as distinguished from an EMR, is intended to be accessibleacross different health care providers.

This disclosure also pertains to providing a tool facilitating expansionof the electronic health records (EHR) to correlate the EHR describeddiagnosis, treatment or service to a third-party medical serviceproviders payment coding scheme. Annotating or recording each healthcare provider's record of diagnosis and treatment with the CPT or ICD,now principally utilized solely as a billing coding protocol, allowsother medical service providers with expedited and efficient access topast patient medical records. The third party payor coding protocol canbe used to provide medical providers with access to the patient's EHR.The coding protocol can be used as an index search a patient's EHR.

The patient diagnosis and treatments records contained within theindividualized EHR can be indexed by patient identity, e.g., name, SSN,service provider assigned patient number, Insurance policy number, etc.

Indexing EHR And Search Overview

This disclosure pertains to a tool that electronical records clinician'sdiagnostic or treatment notes that can be incorporated in the relevantpatient's EHR. The tool also displays the accepted diagnostic andtreatment coding protocols correlated to the clinician's notes. Thecodes may be adapted by the clinician. Theses incorporated codes createan index of the patient's medical records by the billing coding numbers.This indexing, created by the use of the tool, will allow a medicalservice provider to search and receive past patient's treatment recordsby the service (diagnosis, treatment, laboratory test results, etc.).The relevant past medical service records are accessed by utilization ofthe uniform service coding protocol. The relevant past medical recordsare accessed via this diagnostic and treatment tool. The codingprotocol, utilized to facilitate medical payment, can be expanded to beused to search individual EHR records. Searched by medical treatmentcode numbers would substantially narrow the scope of review required ofhealth care providers. It would also save time and effort of the pasthealth care providers in searching and copying records. The instanthealth care provider would have greater confidence in the accuracy ofthe records received from individual past providers, in contrast toreceiving redacted records from one or more central clearing house orthird party service.

Requesting medical records by patient name or SSN will result in atotality of all medical records i.e., EHR, pertaining to that patientbeing provided. However, the party requesting the records (the requestorbeing another medical service provider providing current medicalservices related to a past medical treatment) may be interested only inmedical records pertaining to a specific medical condition, e.g., thepatient's knee or knee injury.

For example, an orthopedic surgeon evaluating treating a patient forcomplaints of left knee pain may be interested in records pertaining topast left knee orthoscopic surgery. The orthopedic surgeon may not beinterested in medical records pertaining to the patient's pasthospitalization for pneumonia. In this situation, it would be productiveand time and cost efficient to request medical records for patient thatpertain past diagnosis, treatment or testing (e.g., X-rays) to patient'sleft knee. This disclosure teaches a method for prompt receipt ofrelevant EHR pertaining to the left knee by requesting the EHR by thepatient's identification and the relevant diagnosis and treatment codes.The codes utilized for billing purposes also have an expanded utility ofprompt and efficient receipt by a health care provider of past diagnosesand treatment.

The search request could specify records associated with particularbilling codes for knee surgery, X-ray or other imaging of the left knee,pharmacologic treatment for inflammation or treatment of arthritis.

In one embodiment, a search request may comprise the patient's name,date of birth and possibly other identifying information such as socialsecurity number, address, date of past services (if known) and a consentfor release of information signed by the patient. (This consent can beobtained as part of the patient's initial information disclosure to thehealth care provider.) The search request would also describe theinstant treatment issues and possibly the code or codes associated withthat medical issue. The recipient of the search request may only berequired to locate the records, and submit records responsive to thelisted coding information. It of course will appreciated that the fullEHR may be later submitted if requested.

It will be appreciated that over time, an individual patient's EHR willincrease in size as the patient receives additional medical examinationsand treatments for multiple medical events or conditions. It willfurther be appreciated that the subject matter of the treatments willvary. It is not time or cost efficient for the voluminous totality ofpast medical treatment records (PHR) be solicited from multiple serviceproviders and then parsed for information pertaining to the instantmedical event. Even if the patient's records are at one location, it isnot feasible to quickly parse through voluminous records that pertain tomultiple diagnoses and treatment to find information specific to theinstant illness or trauma.

Under current practice, the providing of medical services includes thesteps of (i) patient identification, (ii) identification of patientpayment mechanism for medical services, (iii) examination, (iv)diagnosis (v) treatment (vi) submission of records for coding, (v)submission invoice to third party payor for payment, and (vii) recordretention. There may also be the step of adding the records to thetotality of the EHR. The retained records are not under currentpractice, however, correlated to the assigned payment coding. However,the payment coding scheme or protocol is intended to have acomprehensive number set for all diagnoses, treatment, surgery, drugtherapy and ancillary services such as X-ray, test scans (e.g., MRI) andlaboratory work and testing. This disclosure teaches an expanded use ofthe ICD or CPT codes from merely a tool for classifying treatment anddiagnosis for billing but to provide a comprehensive index of medicaltreatment.

EHR Coding Protocols

The current practice utilizes one of several existing coding schemes.One coding protocol is the International Classification of Diseases(ICD). The ICD has been created by the World Health Organization. Thisclassification or coding scheme is, like other classification or codingprotocols, continually updated as treatment procedures expand and aresupplemented. Currently utilized ICD-10 contains over 50,000 separateavailable code entries.

The ICD coding protocol (currently identified as ICD-10 for tenthupdated revision and implemented beginning in 2015) is broken down intocategories and subcategories and may contain as many as 7 digits. Thedetail of the ICD-10 coding is sufficient to distinguish between theright and left side of a patient, e.g., the coding distinguishes betweenthe right and left arm.

Published examples of the ICD code include:

B01.2 Varicella pneumonia

K21.0 Gastro-esophageal reflux disease with esophagitis

030.003 Twin pregnancy, unspecified, third trimester

The ICD code structure is

-   -   a. Characters 1-3—Category    -   b. Characters 4-6—Etiology, anatomic site, severity, or other        clinical detail    -   c. Characters 7—Extension

Note that for the first entry above, B01.2 is the applicable code.Varicella pneumonia is the code descriptor.

The following example shows the more detailed information gained throughthe added characters.

-   -   S52 Fracture of forearm    -   S52.5 Fracture of lower end of radius    -   S52.52 Torus fracture of lower end of radius    -   S52.521 Torus fracture of lower end of right radius    -   S52.521A Torus fracture of lower end of right radius, initial        encounter for closed fracture

In the above example, S52 is the category. The fourth and fifthcharacters of “5” and “2” provide additional clinical detail andanatomic site. The sixth character in this example indicates laterality,i.e., right radius. The seventh character, “A”, is an extension thatprovides additional information, which means “initial encounter” in thisexample. See AMA publication entitled “Preparing for the ICD-10 CodeSet: Oct. 1, 2015 Compliance Date. See AMA publication entitled“Preparing for the ICD-10 Code Set: Oct. 1, 2015 Compliance Date”, 2014.

Search of the ICD-10 CM for “knee ligament” returns multiple entries.See FIG. 10. Entries include, but are not limited to, the followingexamples:

a. S83.4 Sprain of collateral ligament of knee b. S83.5 Sprain ofcruciate ligament of knee c. S83.401A Sprain of unspecified collateralligament of right knee d. S83.4015 Sprain of unspecified collateralligament of right knee, sequela e. S83.4015 Sprain of unspecifiedcollateral ligament of left knee, sequela f. S83.501A Sprain ofunspecified cruciate ligament of right knee, initial encounter g.S83.512A Sprain of anterior cruciate ligament of left knee, initialencounter h. S83.512D Sprain of anterior cruciate ligament of left knee,subsequent encounter i. S83.512S Sprain of anterior cruciate ligament ofleft knee, sequela j. S83.521A Sprain of posterior cruciate ligament ofright knee, initial encounter k. S83.512D Sprain of posterior cruciateligament of right knee, subsequent encounter l. 583.512S Sprain ofposterior cruciate ligament of right knee, sequela

There are two ICD-10 protocols. The ICD-10 CM is the most well knowncoding protocol. ICD-10 PCS on the other hand, is used in hospitalinpatient settings for inpatient procedure coding. Other codingprotocols must be used for classifying treatment, e.g., CurrentProcedural Terminology (CPT) created and maintained by the AmericanMedical Association. Note that the ICD-10-PCS protocol does not replaceCPT codes used by physicians. (The CPT is a registered trademark of theAmerican Medical Association (AMA). The CPT is also copyrighted andmaintained by the AMA.)

It will be appreciated that the existing code protocols have tens ofthousands of individual codes. Each code has a code descriptor. Twoknown protocols are the International Categories of Diagnosis (ICD)promulgated by WIPO, and the Current Procedural Terminology (CPT)promulgated by the American Medical Association. Both the ICD and CPTcode protocols include multiple categories and levels ofclassifications, i.e., classes and subclasses. There are also manymultiple sub categories. Below is a brief overview of the several codeprotocols and their respective classification schemes. It will beappreciated that the use of the ICD and CPT code protocols are used onlyas examples and the teachings of this disclosure will also apply equallyto other code protocols.

The CPT code is another medical code set that is used to report medical,surgical, and diagnostic procedures and services to entities such asphysicians, health insurance companies and accreditation organizations.CPT codes are the United State standard for how medical professionalsdocument and report medical, surgical, radiology, laboratory,anesthesiology, and evaluation and management (E/M) services.

The five-character CPT codes are used by insurers to help determine theamount of reimbursement that a practitioner will receive for servicesprovided. This has been the primary function of the code protocols. Thecodes have not been directly used as a tool of treatment.

Current Procedural Terminology (CPT) codes were first published in 1966and are developed, maintained, and copyrighted by the American MedicalAssociation (AMA). Thousands of CPT codes are in use, and they areupdated annually.

The CPT is divided into three categories of codes. Category I:Procedures that are consistent with contemporary medical practice andare widely performed. Category II: Supplementary tracking codes that canbe used for performance measures. Category III: Temporary codes foremerging technology, services and procedures.

A sampling of the CPT coding scheme is as follows:

-   -   a. Codes for Evaluation and Management: 99201-99499    -   b. Codes for Anesthesia: 00100-01999; 99100-99150    -   c. Codes for Surgery: 10021-69990    -   d. Codes for Radiology: 70010-79999    -   e. Codes for Pathology & Laboratory: 80047-89398    -   f. Codes for Medicine: 90281-99199; 99500-99607    -   g. Individual sections are then broken down further. For        example:    -   h. Office/other outpatient services: 99201-9215    -   i. Hospital observation services: 99217-99220    -   j. Hospital inpatient services: 99221-99239    -   k. Consultations: 99241-99255*        -   i. Problem focused: 99241        -   ii. Expanded problem focused: 99243        -   iii. Detailed: 99244        -   iv. Comprehensive: 99245        -   v. Emergency department services: 99281-99288        -   vi. Critical care services: 99291-99292            -   *Note the physician must provide enough detail to                support the level of service. A problem focused visit                evaluates one to five elements within a system. An                expanded problem focused visit evaluates at least six                elements. A detailed visit evaluates at least two                elements in six systems or 12 elements in two or more                systems. A comprehensive exam evaluates the entire                review of systems, identifying one or two elements per                system.

In addition to the CPT codes, some third-party payors require use of theHealthcare Common Procedure Coding System (HCPCS). The HCPCSincorporates two levels, i.e., the first level consists of the CPTcodes. The second level identifies medical products and services notincluded within the CPT coding scheme. An additional coding protocol isthe Diagnostic Related Grouping (DRG) codes. This coding protocol isused only to code inpatient billing claims.

As used herein, “patient electronic medical records” (or EMR) includesbut is not limited to machine readable electronically stored recordsincorporating ICH, CPT or HCPCS code protocols. The EHR records containthe recorded text of the health care provider's observations of thepatient, patient history and diagnosis, as well as treatment notes,record of ordered tests and test results. It may also contain images,e.g., X-rays and CT scans.

Primary Difference between ICD-10-CM and ICD-10-PCS

When most people talk about ICD-10, they are referring to ICD-10CM. Thisis the code set for diagnosis coding and is used for all healthcaresettings in the United States. ICD-10PCS, on the other hand, is used inhospital inpatient settings for inpatient procedure coding.

ICD-10-CM Breakdown

-   Will replace ICD-9-CM-   Approximately 68,000 codes-   3-7 alphanumeric characters-   Facilitates timely processing of claims

ICD-10-PCS Breakdown

-   Will replace ICD-9-CM for hospital inpatient use only. ICD-10-PCS    will not replace CPT codes used by physicians. According to    HealthCare Information Management, Inc. (HCIM), “Its only intention    is to identify inpatient facility services in a way not directly    related to physician work, but directed towards allocation of    hospital services.”-   ICD-10-PCS also comprises 7 alphanumeric characters-   ICD-10-PCS is very different from ICD-9-CM procedure coding due to    its ability to be more specific and accurate. “This becomes    increasingly important when assessing and tracking the quality of    medical processes and outcomes, and compiling statistics that are    valuable tools for research,” according to HCIM.

Coding Function

It will be further appreciated that one function of the coding protocolsor coding/classification schemes is to convert or translate that medicalhealth care provider's notes of diagnosis and treatment into auniversally understood common “language”. Treatments and proceduresperformed by various providers can be readily identified the commonlyassigned treatment/procedure codes. However, currently, this commonlanguage is utilized only for billing purposes. The object of thisdisclosure includes expanded utilization of this common “language” toprovide an index of patient specific medical diagnosis, treatment andtesting index. This index can be used, in one embodiment, for searchinga patient's EHR for relevant past medical diagnosis, treatment andtesting.

This disclosure teaches integrating the assigned codes with the specificmedical information or portion of the patient's electronic health record(EHR). In accordance with this disclosure, the EHR is annotated with theassigned medical/insurance codes. The patient's EHR (containing pastmedical services, treatment, procedures, surgeries, etc.) can besearched by requesting records associated with specified codesapplicable to the current medical event, i.e., illness, injury, trauma,surgery, etc.

For illustration, typing the term “kidney stone” returns one exact matchunder the ICD-10 protocol, i.e., “Calculus of kidney and ureter” N20.Related ICD terms are: N13 Obstructive and reflux uropathy, N21 Calculusof lower urinary tract, N42 Other and unspecified disorders ofprostrate, Z84 Family history of other conditions, Z87 Personal historyof other diseases and conditions.

Continuing with the illustration, entry of the term “knee ligament”returns approximately 20 direct CPT match entries. There areapproximately another 50 partial matches. There entries are contained inFIG. 9. Entering the term “torn knee ligament” returns 12 direct keywordmatches.

In an embodiment of this disclosure, the health care provider providesmedical examination services for a patient experiencing pain in his/herleft knee. The examination may result in a diagnosis. This diagnosis isrecorded in the service provider's record or file for the patient.Typically, this record may, or may not, contain entries of priorexamination or treatment procedures. The service provide is typicallyrelying upon the patient's memory regarding past treatment anddiagnosis. In recording the instant examination for left knee pain, theservice provider may notate the ICD code applicable for the diagnosis.This code is part of the patient's EHR record.

In a further example, the patient files are electronically recorded. Inone embodiment subject of this disclosure, the ICD diagnosis code ispart of the electronic record. The patient's electronic record may besearched for diagnoses for left knee pain by entering the ICD or CPTcode. It will be appreciated that multiple codes may be entered as asearch criteria wherein these multiple codes pertain to various topicsor procedure related to the left knee.

The search may be broadened for other diagnoses pertaining to the leftknee by entering the first three characters of the ICD code for the leftknee. Note, the simple entry of “left knee” returns 2180 possibleentries. For example, M25 is the code for “other joint disorder, notelsewhere classified”. This code entry is expanded by approximately 9sub sets such as M25.01, “fistula of joint” and M25.5 “pain in joint”.Note further that the entry of right knee returns the same codes. Ageneric or broad entry of “right elbow pain” returns only the generalcode M25.5.

Code Searching

This disclosure includes integrating the diagnosis or treatment code(s)with the patient's electronic health record (EHR). Although EMR and EHRare sometimes used interchangeably, the EHR is deemed to have broaderinclusion of records than may be contained in the electronic healthrecord (EMR). The health care provider's records may comprise a formatwhere the ICD code (or other code) is distinguished from the text of thediagnosis to facilitate electronic search of records. The electronicsearch tools may include, but are not limited to, optical characterrecognition (OCR) components. The ICD may be separated from the text bycolumns, font size or font characteristic, etc.

In one embodiment of this disclosure, a CPU of a medical serviceprovider is programed to contains one or more databases of medicaltreatment activity or medical diagnosis where each database containsactivity or diagnosis descriptions with corresponding code designators.The EHR is also searchable and readable by the CPU. Activity data ordiagnosis data is entered into the CPU by the health care provider; theCPU evaluates the data entry in comparison to the databases; the CPUmatches the data entry with one or more database diagnosis or activitydescriptors and corresponding diagnosis or activity database codes; theCPU records the data activity or diagnosis descriptor and one or morecorresponding database codes into a patient database. The search resultsmay be displayed to the current health care provider. In an embodiment,the database may be ICD or CPT databases.

It will be appreciated that the CPU may comprise a mobile device such asa tablet computer, e.g., iPad, or a smart phone. In another embodiment,the CPU may be positioned on a cart and wheeled into the patientexamination area (patient encounter) or treatment area. The CPU (i.e.,“device”) display screen can be used to display various options or dataentries made by the medical provisional. It can also display suggestedcode selections. The device display can also provide other options suchas a search option as will be discussed below.

In another embodiment, an activity or diagnosis is entered into the CPUalong with at least one corresponding ICD or CPT code.

In another embodiment, the CPU records the combined entered descriptionof activity or diagnosis along with the database codes corresponding tothe entered description.

In another embodiment, the CPU recorded data includes the patient'sidentity criteria. In another embodiment, the date of treatment ordiagnosis is included in the recorded information within the database.The recorded data is indexed by treatment activity, diagnosis orassigned ICD or CPT code. The database may also be indexed by patientname, DOB, address or other identifier. The identifier may be one ormore assigned patient identification numbers. It will be appreciatedthat different health care providers may assign different patientidentification numbers.

It will be appreciated that a patient identifier, (e.g., patient name,patient name and DOB, health care provider identification number, SSN,etc.) may be entered into a database with one or more activity ordiagnosis codes. The database may return records or data of pastdiagnosis or treatment activity. It will be appreciated that the recordsor data may be electronically record health care records from multiplehealth care providers pertaining to the identified patient. Theserecords may comprise the patient's EHR. The records received from thesearch will be limited to the data pertaining to the entered codes. Inanother embodiment, the database will return records of treatment ordiagnosis that related or similar to the entered search codes or searchwords.

As stated above, the ICD-10 contains over 50,000 separate available codeentries. Correctly assigning a correct code for a diagnosis or treatmentcan be a daunting task. However, it is very important that the diagnosisor treatment of a health care provider be correctly coded if the patientelectronic medical record is to be useful to subsequent health careproviders. Hence the value of the code suggestion function taught bythis disclosure.

In recognition of this issue, this disclosure also includes a method forthe electronic medical record to suggest possible classification codesbased upon information inputted into a CPU by the health care providerto for the creation of the electronic medical record. This entry of datamay be current with the health care provider's examination or treatmentof the patient. Thus the health care provider receives the suggestedcode and descriptor (based upon the health care providers entry of data)in real time. Thus the health care provider may be prompted to modifythe entered terms for greater accuracy within the EHR. This applicationincorporates herein by reference U.S. Pat. No. 5,845,300 issued Dec. 1,1998 to Ross Ward Comer et al., U.S. Pat. No. 5,978,766 issued toWilliam W. Luciw on Nov. 2, 1999, and U.S. Pat. No. 8,670,979 issued toThomas Robert Gruber et al. on Mar. 11, 2014. These patents areincorporated herein by reference in their entirety. These patents teachcomputer readable storage medium related to operating an intelligentautomated assistant. The assistant can respond to speech input.Accordingly this disclosure includes the health care provider dictatinghis/her evaluation or treatment and immediately receives the codes anddescriptors.

Accordingly, this disclosure teaches a system for improving theefficiency and reliability of a health care provider entering datapertaining to a patient into a patient specific database or spreadsheetcomputer program containing medical diagnosis, treatment, procedure,tests, etc., by providing suggested entries, including but not limitedto codes, (e.g. ICD, CPT) or completions to the data entry operator,e.g, health care provider. The entries can include, but are not limitedto, alpha-numeric, alpha or numeric codes contained in a medicalprovider service code protocol. The operator enters data regarding thedescription of diagnosis, treatment or testing into a particular dataarea and a dynamic list of possible codes is generated based on enteredtext for the diagnosis, treatment or testing, etc. See the suggestedscreen for data entry presented in FIG. 3 a.

FIG. 1 illustrates an embodiment 100 of the disclosure wherein theutilization of the device and method subject of the disclosure beginwith a patient encounter 101. Information is optained and the clinicianmay enter symptoms or diagnosis 102. Suggested codes, e.g., ICD codes,may be suggested by the CPU and displayed on the device 103. Theclinician may optionally review the suggested codes, alter the notes ofsymptoms or diagnosis review and select alternate or secondary codes104. The clininican may select the primary and secondary codes into thepatient's EHR 105. The clinician may optionally initiate a search of thepatient's EHR using the primary or secondary codes 106. The diagnosisand selected codes may be used to initiate an invoice for reimbursementof services 107.

Autocorrect and Suggestion Functions

The classification process (creating coding classifiers or enhanced codedescriptors) may begin with a first text entry. At least two predicatedcode classifiers are selected for the entry. The predicted codeclassifiers may be selected using a document information profile such asestablished code descriptors. The user's code selection may be used toestablish a code classification.

Note that the user, i.e., health care provider, may reject eachsuggested code and enter a code search term as part of the ICD or CPTfunction, e.g., left knee ligament strain. The search term may presentother suggested codes based upon the ICD or CPT code function.Alternatively, the user may alter or amend the text of thediagnosis/procedure/test entry to achieve a different selection ofsuggested codes.

A processing order for scoring a subset of the selected code(s) may bedetermined, i.e., for each of the predicted classifiers or codedescriptors, a set of scores may be calculated for an EHR entry (“leftknee ligament strain) using the processing order and documentinformation profile (classifier or code descriptor) of the entry to bescored. In response to receiving a user coding decision, data thatcorresponds with the received user coding decision may be identified(e.g., a set of scores calculated for a predicted classifier).

As described, the system facilitates the assignment of these indexingcodes by the health care provider. This may reduce the time and expenseof separate individuals deciphering the health care providers notes andthen assigning codes. It will be appreciated that the ICD code protocolcontains approximately 78,000 separate codes. The system subject of thisdisclosure may display suggested codes to the health care provider atthe time the provider is making his/her entry into the patient'selectronic file.

Significantly, utilizing machine learning as part of artificialintelligence, the system may learn to assemble more accurate sets ofsuggested codes in response to the health care provider's text entry.This learning may be based upon prior text entries, search results andselected codes. The learning could be based not only upon the suggestedcodes that are selected by the health care provider, but the finalbilling codes entered for the patient's health care event. The goal isto create a common vocabulary and definition of terms between the healthcare provider and the code descriptors of a code protocol.

Therefore, the system/algorithm may learn from a user's textdescriptions and past selected codes, i.e., the set of text terms thatlead to a coding selection. The code description (in combination withthe code descriptor) can be either expanded or narrowed, i.e., theoriginal code descriptor can be amended to result in suggestion of acode correlated to the user's text entry within the EHR. The health careprovider will not have to amend his/her vocabulary to match the codedescriptors of the code protocol.

The system can utilize an initial user selection of text or word entriesthat may be broader than the code descriptors of the ACD or CPTprotocols.

The existing protocol or expanded protocol can be used as key words forselection of codes (coding decisions) by the health care provider.

Further, the system (machine learning algorithm) can extract informationprofiles and themes from the health care provider's text entry (i)created as part of the diagnosis step, (ii) from the treatment procedureand progression or (iii) from evaluation of test results. The system mayalso use accepted descriptions of treatment procedure (such asdefinitional terms or phrase of treatment/procedures such as anappendectomy) or the text and range of test protocols. This learningfunction can discern test results outside accepted ranges and classifyor define the resulting test condition (e.g., hypoglycemic).

Also, the system may develop identifiers or classifiers that result insuggestion of one or more codes, i.e., use of the identifiers. Theseidentifiers may be deemed to be enhancements to the code descriptorspublished with the original code protocol. It will be appreciated thatcode descriptors are established by the authors of the establishedcodes. For example, the CPT is a copyrighted property and creation ofthe AMA.

The extraction of information to develop amended identifiers for thecode should increase the accuracy of the suggested codes to the healthcare provider's descriptive text entry for a diagnosis, etc.

It will be appreciated that suggestion of codes for a single patiententry, including the development of identifiers that will be used by thesystem, is repeated for all other patients. The system thereby iscontinuously learning and refining the code identifiers beyond simplymatching the code descriptors to health care provider text entries. Thisis active learning.

Further, the system algorithm may rank the suggested codes by how wellthe text, etc., fits with the code identifiers. As stated above, thecode identifiers are enhancements to the descriptors of the codeprotocols. The ranking may be by the number of letters within the textthat match the code descriptor. Alternatively, the ranking may be basedon whether there is a text match of a noun versus adjective of the noun.A match of nouns between the code descriptor and text entry may rankhigher that a match of adjectives.

The codes, along with the code descriptors, are established in the codeprotocol. The EHR entries (frequently termed herein as“diagnosis/treatment/tests) can be classified or indexed using the codedescriptors. The active learning algorithm may classify the EHR entriesby a process that may be termed “forking”, i.e., creating a number ofclassification paths corresponding to predicted user's (i.e., healthcare providers) coding decisions. See FIGS. 9A, 9B and 11 discussedinfra. Further, the active learning algorithm may determine an order inwhich individual EHR entries of the EHR patient record may be processedand scored utilizing the forked classification paths. The use ofpredicted classifiers and forking allows the classification system totake advantage of the latency in review of EHR entries by a health careprovider. Forking allows the classification system to have a least a setof partial calculations ready by the time of the first health careprovider's coding decision. These partial results allow theclassification system to suggest codes in for a next similar text entryin an interactive and real time manner, thereby speeding up the codingprocess.

FIG. 2 illustrates an embodiment of the above described disclosure 149wherein the clinician may initiate treatment using the diagnosisconsistent with the selected ICD codes 150. Treatment or test may beordered 151 152 and treatment initiated 153. The clinician may reviewand select additional codes 154 or the selected treatment codes(secondary and primary) may be entered into the patient EHR 155. Thisstep may be supplemented 156. The entered data can be made subject of aclinician initiated search 157 and preparation and submission of aninvoice 158.

Another goal is that the suggested codes include the generic code aswell as the species that may be selected by the health care provider (ormodified by amendment of the code descriptor). For example, a codeindexed diagnosis for pain in knee may include broad generic codes forknee as well as one or more species codes for specific to the healthcare provider's diagnosis. The device subject of this disclosure mayallow the health care provider to tailor a search broadly or narrowly.For example, a diagnosis of pain in the patient's right knee mayinclude: “M25.561 Pain in right knee”. However, in one embodiment, thehealth care provider may request a broader search, to include the code:“M25.56 Pain in knee”.

In another example, and referencing FIG. 14a 5a discussed below, thehealth care provider may enter the class descriptor ICD-10-CM S83Dislocation and sprain of joints and ligaments of knee. This classdescriptor correlates to the suggested subclasses S83.412A, S83.522A andS83.512A listed in FIGS. 14a 5 a.

In yet another example, the health care provider may elect broad searchto include the following ICD-10 codes:

-   -   i. M17 Osteoarthritis of knee    -   ii. M24.56 Contracture, knee    -   iii. M24.66 Ankylosis, knee    -   iv. M25.16 Fistula, knee    -   v. M25.46 Effusion, knee    -   vi. M25.76 Osteophyte, knee    -   vii. M67.46 Ganglion, knee    -   viii. M94.26 Chondromalacia, knee

These codes are directed to distinct anatomical structures of the kneeas selected by the health care provider.

In another embodiment, the health care provider input device may allowthe user to select the scope of the search from “narrow” to “broad”,thereby automatically adjusting the scope of the codes and codedescriptors (stored in the device memory) to be included in the searchof prior patient EHR records. In yet another embodiment, the health careprovider may select among the above 8 listed categories of ICD-10 codes.

In yet another embodiment, the health care provider may request that thelisted medical code entries of an ICD-10 or CPT code protocol becorrelated to include similar code entries of at least one of thefollowing alternate codes protocols, Healthcare Common Procedure CodingSystem (HCPCS), Diagnostic Related Grouping (DRG) codes, etc.

Using the identified data, i.e., the EHR entry, the code and the codeclassifier/descriptor, the text of the EHR entry may be classified bythe algorithm of the system into one or more of the classes orsubclasses. It will be appreciated that this will enhance the returns insubsequent searches.

The collection of created code classifiers may be the composition ofmultiple EHR records pertaining to multiple patients. It will beappreciated, however, that information contained in one patient's EHR isnot transferred or disclosed in relation to another patient. Rather,this is a process initiating and continuing the active learning of thesystem algorithm. In addition, a processing time may be allocated forcalculating the set of scores corresponding to a subset of selectedcodes.

In one embodiment, the system algorithm is additionally capable ofreceiving or providing relevance rankings to a subset of selected codes.The ranking process may be derived from the health care provider'sselection of codes. For example, relevance rankings may be generated by(a) one or more keyword searching algorithms or by (b) a comparison withone or more exemplary documents (e.g., documents from or outside of thecollection such as teaching EHR entries). Additionally, a (c) processingorder for the documents to be scored may be derived using the identifieddata and relevance rankings. A document may be selected by choosingbetween rankings generated from the identified data, relevance rankingsor a combination of the identified data and the relevance rankings.Furthermore, systems, methods, and computer readable media are capableof managing priority queues for ranking the documents of the documentcollection. Priority queues may be ranked or ordered using identifieddata and/or relevance rankings.

The coding classifiers may be updated or amended based upon theselection history of text used by health care providers in EHR recordentries. This is a function of machine learning of the code selectionmade by at least one health care provider corresponding the provider'stext entries or data entries pertaining to patientdiagnosis/treatment/test. The Systems, methods, and computer readablemedia are also capable of updating a code identifier (amended codedescriptor) based on the health care provider's selection of a suggestedcode in relation to the health care provider's entered text and alearning rate for limiting the effect of the single code selection andcorresponding EHR text.

It will be appreciated that there exists a pattern between relevantwords of the code descriptors/identifiers and the text entries. The text“knee” will statistically have a set of adjectives, e.g., “sprain”,“torn”, “strained”, “pain”, etc. Also the code identifiers will becreated based upon the health care provider's selection of codes (andthe code descriptors) for multiple EHR text entries. It will beappreciated that the text entries may use a different but relatedvocabulary to describe the same patient condition. Finally, it isdifficult to formulate a mathematical expression showing therelationship between text entries and possible code identifiers. It istherefore useful to employ a mapping function utilizing a machinelearning algorithm that maps a relationship between the input data,i.e., text entries and the output data, i.e., elected codes. Theutilization of the mapping function can be said to achieve anapproximated target function. The approximation may utilize one or moreassumptions and the assumptions may be refined over the course ofevaluating multiple input data, i.e., entries of the health careprovider entered into multiple EHRs. The fact that a large number ofentries may be made in performance of the diagnosis/treatment/testactivities justifies valuable use of machine learning.

It will be appreciated that an alternate but related method to machinelearning would be studying the relationship of the input data, therebycreating a statistical inference. It will also be appreciated that themachine learning continues with the creation of each EHR text entry andselection of applicable codes.

In yet another alternative, it may be possible to assign numericalidentifiers to set of text words, e.g., knee, elbow, femur, tibia,pelvis, stomach, lung, etc. Also, numeric identifiers could beassociated with adjectives, e.g., swollen, edema, enlarged, engorged,sprain, torn, sore, strained, inflamed, etc. The combined numericvariables could be iteratively refined over a set of EHR text entriesevaluated and the numeric variables of selected code identifiers (outputvariables) can be expressed as a combination (weighted sum) of the setof numeric input variables.

Additionally, systems, methods and computer readable media are disclosedfor implementing an embodiment of the disclosed system as auser-friendly, disposable, integrated, portable, turnkey solution. Forexample, the above described classification tool may be implemented onsingle a device (e.g., a standard PC computer, tablet, laptop,smartphone, or other device) utilized by a health care provider. Suchdevices are elsewhere referred to a client device or user device. Such adevice may run a standard operating system (e.g., Windows, Linux, OSX,Android, iOS) and the classification system is conventionally installedas one or more programs or libraries on the device itself. When thedevice is, for example, a laptop, tablet, or smartphone, theclassification system is easily transportable. Such a device may or maynot be further connected to one or more computers or other devices via anetwork or it may be connected via a WiFi system. Alternatively, theclassification system may be contained on computer readable media (e.g.,a CD, hard disk, USB drive, and/or other bootable media) which, wheninserted or coupled to the device, causes the classification system tobe run entirely on the device. Such a device may or may not be furtherconnected to one or more computers or other devices via a network.

The above systems, methods and media therefore increase the overalleffectiveness of the classification effort by improving both precisionand recall, while requiring less computational resources (e.g.,workstations, servers, and infrastructure), and less manpower toinitiate, maintain and oversee document classification. Moreover, incertain embodiments, the speed of the classification effort is improvedthrough the use of classification vectors rather than matrices, withfurther improvements realized by reducing the dimensionality of thevector space and/or by using binary values to represent the vectorelements.

This disclosure includes providing multiple suggested codes based upon amachine evaluation and learning of the word content of the health careprovider's text EHR entry to the word content of the code descriptor.

The system algorithm provides enhanced classification EHR entriescreated by health care providers. The algorithm improves upon the set ofsuggested health care codes (for example ACD and CPT code protocols)that can be presented/suggested to the health care provider whencreating an electronic record of a patient diagnosis, etc.

It is a goal of the disclosure to provide an improved method ofassigning specific alphanumeric code entries to individual text entriescreated by the health care provider. The disclosure includes presentingsuggested code entries to the health care provider as the entries arecreated based upon matching the subject matter of the text entries withcode classifiers that have be assigned by the creators of the codeprotocols. Examples of code protocols include ICD-10 and CPT. Also, forexample, multiple codes contained in a code protocol may be relevant toan entry of “left knee strain”. It will be appreciated that in each codeprotocol, every alphanumeric code is accompanied by a relatively briefdescription, hereinafter termed a “code descriptor”.

Further, this disclosure includes incorporating the relevant/applicablecode or codes into or indexed with the health care provider's individualtext entry. The code becomes part of the patient's EHR. The EHR may besearched by identifying the patient and inputting the assigned code orcodes. Past EHR entries may be searched contemporaneously with thehealth care providers examination of a patient and creation of adiagnosis. The diagnosis will also incorporate or be indexed by thecode.

It will be appreciated that inasmuch as the EHR records are electronic,the EHR should be readily searchable and requested past EHR entriespertaining to the furnished codes can be promptly returned to therequesting health care provider.

Device & Screen Display

Referencing FIGS. 3a-3f , in one embodiment suggested (or selected)codes may appear within the entered text or in a separate designatedarea. For example, the data entry field 302 a may be accompanied by acolumn, row or machine fillable block (“code space”) 301 a located tothe left or right of the data entry field. The code space may bedesignated as “code”, or “diagnosis, treatment, test code” or similar.As the medical professional enters text into the data field, possiblecodes may appear in the designated code space.

The disclosure can include an algorithm that suggests text entries inresponse to data, e.g., text, entered by the health care provider. Thiscan be substitution of words, i.e., “ligament” in place of “liagament”.The algorithm may suggest “knee” in response to the partial text entry“knie”.

In an embodiment, the disclosure includes an algorithm that will suggestICD, CPT, etc., codes in response to an entry “knee ligament” or “tornknee ligament” in contrast to entries for “sprained knee ligament”. Thesuggestion may include, but is not limited to, the five digit code butalso a code description. For example one possible ICD code suggestion inresponse to the “torn knee ligament ” entry could be:

a. “S83.20 Tear of unspecified meniscus, current injury” b. “S83.209Unspecified tear of unspecified meniscus, current injury, unspecified.”c. “S83.209A Unspecified tear of unspecified meniscus, current injury,unspecified knee, initial encounter.”

d. “M23.20 Derangement of unspecified meniscus due to old tear orinjury”

Sample CPT Code Examples:

a. “27405 Repair primary torn ligament/capsule knee collateral” b.“27407 Repair primary torn ligament/capsule knee cruciate” c. “27409Collateral and cruciate ligaments”

See for example FIG. 3a . Illustrated is an embodiment of a screendisplay. The health care provider may fill in the patient identifyinginformation 310. The health care provider may proceed to enter thediagnosis, the treatment as applicable as well as either tests orderedor test results. This information can be entered in one or more textblocks 302 a, 302 b, etc. The applicable codes may be entered in thecode spaces 301 a, 301 b, etc. In a preferred embodiment, the suggestedcodes may populate the code spaces as the health care provider types orenters text in the text block. The suggested code may be in reversevideo (designated herein by the brackets [ ]). This auto insertion ofsuggested codes is a function of the data entry program as describedmore fully below. The health care provider can accept the one or more ofthe suggested codes or insert the user's own selection. FIG. 3a shows asample diagnosis 302 a and concurrent display of ICT codes applicable tothe diagnosis 302 a. The codes and descriptors are added automaticallyby the algorithms subject of this disclosure.

Referencing FIG. 3b and continuing with the example, the health careprovider could enter a test or treatment in text space 302 b. The healthcare provider determines to X-ray the knee. This is entered in textspace 302 b. The disclosure algorithm suggests three alternate X-raytests. The CPT codes and descriptors are displayed in the code space 302a. The suggested text is in reverse video, i.e., here initialized andcontained in brackets [ ]. The health care provider can select one ofthe suggestions. FIGS. 3a and 3b illustrate one embodiment as to thedisplay format and sequence of diagnosis/treatment/test text and thesuggested code(s).

The text blocks 302 a, 302 b may also utilize an auto fill featurewherein entering “knee” in the text space, e.g., 302 b, may result inthe appearance of one or more suggestions such as “knee inflammation”,“knee ligaments”, “knee meniscus”, etc. These suggestions may alsoappear in reverse code. The user may select one of the selecteddescriptions for diagnosis or treatment. It will be appreciated that thesuggested applicable code(s) for each suggested expanded description maysimultaneously appear in the code space in reverse video. Further, itwill be appreciated that upon selection of the expanded or alternatediagnosis or treatment description, the code and descriptor will appearin the code space, e.g., 301 a. In one embodiment, the suggested codewill be displayed in reverse code for acceptance by the health careprovider.

The suggested code selection may be based upon text entered by thehealth care provider. It may also be based upon the health careproviders past use of terms. As the health care provider enterscharacters of text data item, the list of corresponding diagnosis,treatment or test codes are searched for an entry that is appropriatefor or matches the entered data item. If a code match is found, then thematching code (or codes) is displayed in the code space to the healthcare provider as a suggested completion. The health care provider canthen elect to accept the suggested completion or to continue enteringthe data item.

For example entering the term “torn ligament” may trigger the display ofCPT (or similar) code to appear in the code space. Depending upon thespecificity of the entered text, multiple suggested codes may appear.See FIG. 3f . In the embodiment, the disclosure algorithm displaysalternate suggested codes (in reverse video). In response, the healthcare provider may add descriptive text to the description of thediagnosis/treatment or test appearing in the text block 301 b.Alternatively, the health care provider may select one of the suggestedcodes appearing in code space 301 a. In another embodiment, thealgorithm of the disclosure presents additional text (in reverse video)to provide the location, etc., of the ligament. The health care providermay complete the text data entry and accept the final code or codesappearing in the designated code space. Alternatively, the health careprovider may select a desired code when it appears and complete theentry of text.

In another example, the code space 301 a may be automatically populatedupon entry of pre-selected text in the text space 301 b. This examplemay apply when there are only limited codes applicable to the servicesprovided by the health care provider.

This aspect of the disclosure frees the health care provider fromattempting to memorize the applicable codes or search a code index toselect the appropriate code. This accelerates the data entry process andprovides greater accuracy in entering the correct code for the services,treatment or diagnosis, as well as entering of the description ofservice or treatment.

The display may contain a “Search” button to initiate a search of thepatient's EHR. It may also include a button to reject the suggestedcode. Acceptance of the suggested code may cause the entry to replacethe health care provider's notes or to included within theaccepted/integrated code protocol entered into the EHR.

Auto Correct & Autocomplete System

FIG. 4a illustrates an embodiment of a computer 410 suitable forsupporting the operation of the preferred embodiment of the disclosure.Other configurations are included within the scope of this disclosure.As shown in FIG. 4a , the computer 410 may operate in a networkedenvironment with logical connections to a remote computer 411. Thelogical connections between the computer 410 configured forimplementation of this disclosure and the remote computer 411 arerepresented by a local area network 412 and a wide area network 413.Those of ordinary skill in the art will recognize that in thisclient/server configuration, the remote computer 411 may function as afile server or computer server.

The computer (CPU) 410 includes a processing unit (PU) 414. The computermay also include system memory 415 (including read only memory (ROM) 416and random access memory (RAM) 417), which is connected to the PU 414 bya system bus 418. The preferred computer 410 utilizes a BIOS 419 (BasicInput/Output System), which is stored in ROM 416.

Those skilled in the art will recognize that the BIOS 419 is a set ofbasic routines that helps to transfer information between elementswithin the computer 410. Those skilled in the art will also appreciatethat the present disclosure may be implemented on computers having otherarchitectures, such as computers that do not use a BIOS. Additionally,the present disclosure is not limited to computers that utilize ROM orRAM for system memory. Other technologies such as electronicallyprogrammable ROM (EPROM), ultraviolet light erasable and electronicallyprogrammable ROM (UVEPROM), electronically erasable and programmable ROM(EEPROM), FLASH and bubble memory may also be used.

Within the computer 410, various devices may be connected to enhance theutility and performance of the computer. A local hard disk drive 420 maybe connected to the system bus 418 via a hard disk drive interface 421.A floppy disk drive 422, which is used to read or write a floppy disk423, may be connected to the system bus 418 via a floppy disk driveinterface 424. A CD-ROM drive 425, which is used to read a CD-ROM disk426, may be connected to the system bus 418 via a CD-ROM interface 427.A health care provider or medical coder enters commands and informationinto the computer 410 by using input devices such as a keyboard 428,and/or pointing devices such as a mouse 429. Typically, these inputdevices are connected to the system bus 418 via a serial port interface430 or a parallel port interface (not shown in FIG. 4). Other types ofpointing devices (not shown in FIG. 4) include track pads, track balls,pens, head trackers, data gloves and other devices suitable forpositioning a cursor on a computer monitor or display 431. A monitor 431or other kind of display device may be connected to the system bus 418via a video adapter 432.

The computer may be connected to a network of other computers ordevices. A remote computer 411 in a networked environment is connectedto a remote memory storage device 433. This remote memory storage device433 is typically a large capacity device such as a hard disk drive,CD-ROM drive, magneto-optical drive or the like. The personal computer410 may be connected to the remote computer 411 by a network interface434, which is used to communicate over the local area network 412.

The computer 410 may also be connected to the remote computer 411 by amodem 435, which is used to communicate over the wide area network 413,such as the Internet. The modem 435 is connected to the system bus 418via the serial port interface 430. The modem 435 also can be connectedto the public switched telephone network (PSTN) or community antennatelevision (CATV) network. Although illustrated in FIG. 4a as externalto the computer 410, those of ordinary skill in the art will quicklyrecognize that the modem 435 may also be internal to the personalcomputer 411, thus communicating directly via the system bus 418. It isimportant to note that connection to a remote computer 411 via eitherthe local area network 412 and the wide area network 413 is notrequired, but merely illustrates methods of providing a communicationpath between the computer 410 and the remote computer 411.

Although other internal components of the computer 410 are not shown,those of ordinary skill in the art will appreciate that such componentsand the interconnection between them are well known. Accordingly,additional details concerning the internal construction of the computer410 need not be disclosed in connection with the present invention.

Those skilled in the art will understand that program modules such as anoperating system 436, application programs 437 a-N, and data areprovided to the computer 410 via computer-readable or machine readablemedia. The computer-readable media may include the local or remotememory storage devices, which may include the local hard disk drive 420,floppy disk 423, CD-ROM 426, RAM 417, ROM 416, and the remote memorystorage device 433. In the preferred computer 410, the local hard diskdrive 420 is used to store data and programs, including the operatingsystem and programs.

FIG. 4b is a simplified block diagram illustrating one embodiment of theinteraction between the computer hardware 450, the preferred operatingsystem 436, and an application program 437 a. Referring now to bothFIGS. 4a and 4b , when the computer 410 is turned on or reset, the PU414 is forced to begin program execution at a specific memory locationin the ROM 416. This specific memory location corresponds to thebeginning of the bootstrap routine contained in the BIOS 419. Thebootstrap routine functions to load the operating system 436 from thehard disk drive 420 into the RAM 417. Once the operating system 436 isloaded into RAM 417, the PU 414 executes the operating system 436 andcauses the visual elements associated with the user interface of theoperating system 436 to be displayed on the monitor 431.

The operating system 436, in conjunction with the BIOS 419 andassociated device drivers, may provide the basic interface between thecomputer's resources, the user, and the application program 437 a. Theoperating system 436 interprets and carries out instructions issued bythe user and/or application program(s). For example, when the user wantsto load an application program 437 a, the operating system 436interprets the instruction (e.g., double clicking on the applicationprogram's icon) and causes the PU 414 to load the program code into RAM417 from either the local hard disk drive 420, floppy disk 423, CD-ROM426, or the remote memory storage device 433. Once the applicationprogram 437 a is loaded into the RAM 417, it is executed by the PU 414.For larger programs, the operating system 436 causes the PU 414 to loadvarious portions of program, or program modules, into RAM 417 as needed.In addition, several applications programs (437 a-N) can be loaded intoRAM at the same time. In this scenario, the operating system 436 willswitch the PU 414 execution time between applications based on userrequests, application program request, or by a time-sliced allotment ofthe processing time of PU 414.

The operating system 436 may provide a variety of functions or servicesthat allow an application program 437 a to easily deal with varioustypes of input/output (I/O). This allows the application program 437 ato issue relatively simple function calls that cause the operatingsystem 436 to perform the steps required to accomplish various tasks,such as displaying text on the monitor 431 (FIG. 4a ) or printing texton an attached printer (not shown). Generally described (with referenceto FIG. 4b ), the application program 437 a communicates with theoperating system 436 by calling predefined functions provided by theoperating system 436. The operating system 436 responds by providing therequested information in a message or by executing the requested task.In addition, the operating system may interface to the hardwarecomponents 450 in responding.

FIG. 4c may be used to illustrate the simple state flow for theautocomplete process including entering edit mode 200 for an active cell(i.e., a space for entering a single alphanumeric character), entering apartial text or data item comprising one or more alphanumeric characters210, receiving a suggested completion 240 (comprising one or morecompleted words), and accepting the suggested completion 250, 295. FIG.5, which provides a full state diagram of the AutoComplete process, maybe used to describe the AutoComplete process in detail as consisting ofa state machine with user commands and process events inducingtransitions between states. Finally FIGS. 6, 7 a, 7 b and 8 may be usedto describe additional detail for several aspects of the AutoCompleteprocess.

AutoComplete User Interface

The AutoComplete user interface in one embodiment subject of thedisclosure comprises eight functional areas: (1) Entering edit mode foran active cell; (2) Entering a partial data entry and finding a uniquematch; (3) Accepting a suggested completion; (4) Entering a partial dataitem over a suggested completion; (5) Entering a partial data entry andfinding multiple matches; (6) Entering a partial data entry thatdisables further searches; (7) Obtaining a case conversion for a partialdata entry; and (8) Entering a partial data entry where there are noassociated cells. Each of these functional areas will be described withreferences being made to the user screens in FIGS. 3a-f and the stateflow diagram in FIG. 4 a.

Referring to FIG. 3a , the health care provider may enter text in thedescription block or space 302 a regarding the patient. This may be adiagnosis or note pertaining to the examination or treatment. In oneembodiment, text may be entered directly into the text block 302 a. Thetext may be subject to the autocorrect function (edit function)described below. The text may also be subjecting to the autofill ofsuggested code(s) entered in to the code space 301 a. It will beappreciated that the suggested codes will be determined upon the healthcare provider's text entry into the text block 302 a. In anotherembodiment, the health care provider or coder may directly enter one ormore codes into the code space 301 a.

Referring to FIGS. 3c and 5, in one embodiment, the edit mode for thetext block may be manually activated entered at point by pressing afunction key. In another embodiment, the edit function is automaticallyactivated. The cursor may be located in the middle of text space 302 a,illustrating that text space 302 a is currently active with the editmode being enabled. Referencing FIG. 5, upon entering edit mode 205, alist of completed data items is generated in the BUILD Completion Liststate 210. The list of completed data items may generated from storedcompleted data items pertaining to the text block 302 a of FIG. 3c orfrom a preloaded computer dictionary. The completed data items may bepreviously entered text entries. As will be described in more detailherein below, the list of completed data items will only contain oneentry for each unique data item. It should be noted that the user mayalso enter the edit mode automatically by initiating a text entry in thetext block. After generating the completed text data item list, (FIG. 3acontaining text entry for sprain on left side of left knee 302 a) thealternate completed entries in code space 301 a may be displayed.Referencing FIG. 3c , if a partial text entry is entered, e.g., “Tornlig”, the screen will display a suggested completion text is reversevideo of “ament”. Referencing FIGS. 4c and 5, when the partial textentry of “Torn lig” is entered, the WAIT Partial Entry state 420 isentered.

Entering a Partial Data Entry and Finding a Unique Match:

Entering a partial data or text entry will cause a transition to theATTEMPT AutoComplete state 230 and invoke a search of the list ofcompleted data items to find a completed entry that uniquely matches thepartial text entry. This can be completion of the text entry in FIG. 3c302a or matching code entries in 301 a. The DISPLAY Completion state 240is then entered and the suggested completion text is displayed in thetext space 302 a and the suggested code(s) may be displayed in 301 a. Asuggested completion can be presented to the user by displaying theportion of the suggested completion that contains the partial text orentry in normal video and the remainder of the suggested completion inreverse video e.g., having a distinguishing text color, text backgroundor border. The reverse video is illustrated in FIG. 3a by initializationand brackets, e.g., [ ]. The suggested code can be similarly displayed.

Accepting a suggested completion. Referring to FIG. 3c , the health careprovider has entered “torn lig” 302 a. The autocomplete functionsdisplays the letter string “amens” immediately after the “g” of “tornlig”. At this point the user can either accept the suggested completionor enter an additional partial completion, i.e., by typing an additionalcharacter such as “g”. The scenario in which the user accepts thesuggested completion is illustrated in FIG. 5 by entering the STOREAutoComplete state 250. If the user accepts the suggested completion bypressing the enter key, the edit mode 200 is exited at point 295 (shownin FIG. 5). It will now be appreciated that the text states “tornligament”. The suggested code may be similarly accepted. In anotherembodiment, acceptance of the suggested text, creating “Torn ligament”may result in additional suggested codes being displayed.

A suggest code may be entered into the code space 301 a. FIG. 3cillustrates the insertion of the ICD code for “repair, primary, tornligament and/or capsule, knee, collateral”. The device may be programedto display both the ICD and CPT codes. Alternatively, the health careprovider may select the specific code to be displayed. Note also thatthe code descriptor may also be displayed in 301 a. This will facilitatethe health care provider electing whether to accept the code or, whenmultiple codes may be displayed, to select among the choices.

It will be appreciated that the EHR format of FIGS. 3a-3f is only oneembodiment. Other configurations may be used and additional types ofinformation may be contained within the display. See for example FIGS.12a and 12b .

Entering a Partial Data Item Over a Suggested Completion:

Referring now to FIG. 3c , instead of accepting the suggestedcompletion, the user may modify the partial data item by entering anadditional letter character (e.g., “d”) into the partial word text entry“torn lig” within 302 a. This action may result in another search of thelist of completed data items for a completed entry uniquely matching themodified partial data entry “ligd”. There will be no such entry.Accordingly, the closest matching word is “ligament”. Again, thecompleted data item “ligament” may be displayed in the text space 302 anext to the letter string “ligd”. The suggested autocorrect may be inreverse video (indicated in FIG. 3b by the [ ] brackets). If the userelects to again modify the partial data item by entering the additionalcharacter “m”, then the list of completed data items will be searched toidentify a suggested completion for the twice modified partial dataentry “ligam”. In this example, the completed term “ligament” may againbe displayed in reverse video.

Entering a Partial Data Entry and Finding Multiple Matches:

The results of entering a partial data entry may have multiple matchingitems. The partial entry “Ii” could trigger the suggested completionword text of “liver” or “ligament”. Both suggested entries may be shownin reverse video. In one embodiment, the suggested autocomplete orautocorrect entry may be shown beneath the subject letter string “Ii”.

Entering a Partial Data Entry that Disables Further Searches:

Referencing FIG. 3c , if the user enters the letter “i”, after “lig” themodified partial data entry of “ligi” will not have a matching completeddata item in the completed data item list. When a partial text item isentered and there are no matching completed text items in the computervocabulary (maintained in static memory) then the partial text entry isdisplayed in the text space. However, it will be appreciated that thedisclosure includes an embodiment wherein the entry “ligi” will stilltrigger the word “ligament” (in reverse video) on the display as asuggested appropriate word text for a user error in spelling. This wouldbe an application of an autocorrect application program. The applicationprogram may be enabled to suggest possible corrective word text.

Continuing with the partial text entry, if the user enters additionalcharacters, the list of completed data items may not be searched. Thereason for disabling further searches is that if the completed text itemlist does not contain a match for a partial text entry (i.e., “ligi”),then it will not contain a match for any partial data entry beginningwith the previous partial data entry.

Obtaining a Case Conversion for a Partial Data Entry:

The process of the case conversion in the AutoComplete process isillustrated. In FIG. 3e , the partial data entry “liga” has been enteredand a suggested completion of “ligament” has been found and displayed302 a. Alternatively, the portion of the suggested completion thatmatches the partial data entry may be displayed in normal video inconformance with the capitalization of the partial text entry “liga”.The suggested completed text entry containing the upper case “L” isdisplayed in reverse video. If the user accepts the suggested completionby pressing the enter key, the capitalization in the active cell will beadjusted to correspond to the capitalization of the completed data item.

AutoComplete as a State Machine:

The detailed operation of AutoComplete can be described in the form of astate machine. In general, a state machine is a means to illustrate theoperation of a process by identifying the various unique states in whichthe process can exist and identifying what events or circumstances willcause the process to transition between those states.

Referring to FIG. 5, a diagram of the AutoComplete state machine 200 isshown as consisting of two types of states: static, depicted as a solidcircle; and dynamic, depicted as a broken circle. A static state is asteady state in which an external event must occur in order totransition to a different state. In the absence of an external event, aprocess can remain in a static state indefinitely. A dynamic state is amomentary or transitory state in which a process only exists whileperforming a specific function or task. Upon completion of the task, atransition to another state will occur. A dynamic state generallycomprises the execution of an algorithm and is exited upon completion ofthat algorithm.

The AutoComplete process comprises 3 static states and 4 dynamic states.These AutoComplete states include static states:

-   -   a. WAIT Partial Entry 220;        -   DISPLAY Completion 240        -   DISABLE AutoComplete 270; and dynamic states:        -   BUILD Completion List 210;        -   ATTEMPT AutoComplete 230;        -   STORE 250; and        -   CLEAR 260.

Three types of transitions exist for the AutoComplete state machine andinclude: User commands; Process events; and Background events. The Usercommands, indicated by [xxxxx], occur in response to actions taken bythe user. The Process events, indicated by (xxxxx), occur automaticallyupon the completion of processing in a dynamic state. The Backgroundevents, indicated by (xxxxx) and drawn with dashed lines, occur duringthe idle time between user commands.

The AutoComplete user commands include:

-   -   a. [Partial Entry] 600: Partial data item for a cell;        -   [Accept] 610: Accepts a suggested completion;        -   [Abort] 620: Rejects the data in the active cell;        -   [Disable AutoComplete] 630;        -   [Enable AutoComplete] 640; and        -   [Edit] 650: Enables the edit mode for a cell.

The AutoComplete process events include:

-   -   a. (Suggested Completion) 730;        -   (No Completion) 740;        -   (No Suggestion) 750; and        -   (Exit Edit) 760.

The AutoComplete background process events include:

-   -   a. (Build Level 1) 700;        -   (Complete) 710; and        -   (Build Next Level) 720

Upon entering the edit mode for an active cell, the AutoComplete processwill initiate the performance of two functions. The first function isthe generation of the list of completed text or code items associatedwith the alphanumeric text entries 302 a. In the preferred embodiment,the completed data item list will be generated in a tiered approach as abackground process. The tiered approach consists of building the list ofcompleted data items one level at a time where each level includes aspecific number of possible alphanumeric character spaces. The secondfunction is to identify and provide a suggested completion for a partialtext entry.

Referencing FIG. 5, entering the [Edit] user command 650 causes the editmode 200 to be entered as shown at point 205. The (Build Level 1)process command 700 is issued automatically upon entering edit mode andthe BUILD Completion List state 210 is entered. In the BUILD CompletionList state 210, the first level of the completed data item list isgenerated. In the preferred embodiment, the first level includes the 50alphanumeric character spaces that are most closely associated with theactive cell. As will be described later, this includes the associatedcharacter spaces that are physically closest to the active space. Ifthere are a limited number of text entries (i.e., less than 50alphanumeric character spaces), the first level of the completion listwill include all of the associated entries using a pre-entereddictionary, past usage or compatible code descriptors. After the firstlevel of the completion list has been generated, a (Complete) processevent 710 is executed and a transition to the WAIT Partial Entry state220 occurs. In the WAIT Partial Entry state 220, the application programwaits for the reception of a user command, e.g., acceptance or entry ofanother alphanumeric character.

If there is idle time between entering user commands in the WAIT PartialEntry state 220, and the completion list has not been fully generated, a(Build Next Level) background process event 720 will be issued resultingin a transition to the BUILD Completion List dynamic state 210. (Note,this event may also be issued in the DISPLAY Completion state 240.) Whenthe next level of the completion list has been generated, a (Complete)process event 710 will be issued and a transition to the WAIT PartialEntry state 220 will occur (or a transition to the previous state). The(Build Next Level) background process event 720 will continue to beissued until the list of completed data items has been fully generated.

In the WAIT Partial Entry state 220, four user commands are accepted:[Partial Entry], [Disable AutoComplete], [Abort], and [Accept]. If theuser provides [Partial Entry] 600, a transition to the ATTEMPTAutoComplete state 230 will occur. This transition will occur inresponse to entering the first character in the text space. This is animprovement over similar implementations, which require the entry ofseveral characters prior to attempting to automatically complete theentry.

In the ATTEMPT AutoComplete state 230, the partial text entry will thenbe used as a character mask to search through the list of completed textitems for a unique match. A unique match exists if there is only oneitem in the completed text item list that begins with the same characteror characters defining the partial data entry. A unique match is furtherdefined as, given that an N character partial entry has been entered, ifthere is one and only one text item in the completed text item list thatbegins with these N characters, then that data item is a unique match.If more than one entry matches the first N characters, then a uniquematch does not exist.

The ATTEMPT AutoComplete state 230 can be entered prior to fullygenerating the list of completed text items. If this occurs, the searchfor a suggested completion will be limited to the completed text itemlist in its current state (i.e., the levels that have been generated).But, if updating the list of completed text items results in destroyingthe unique status of the partial text entry, the current AutoCompletesuggestion remains intact until either the user accepts the text item orenters a subsequent partial entry.

As a result of entering the ATTEMPT AutoComplete state 230, one of threepossible outcomes will be realized: (1) a unique match will be found;(2) no matches will be found; or (3) multiple matches will be found.

If a unique match is found, then a (Suggested Completion) process event730 is issued, which results in a transition to the DISPLAY Completionstate 540. Here, [Partial Entry] 600 containing the partial data entry“liga” was entered in the WAIT Partial Entry state 220 and this resultedin a transition to the ATTEMPT AutoComplete state 230. Upon finding theunique match “ligament”, the (Suggested Completion) process event 730issued, which resulted in a transition to the DISPLAY Completion state240 for displaying the suggested completion in the text space or codespace.

If no matches are found, the (No Completion) process event 740 isissued, which results in a transition to the DISABLE AutoComplete state270. Examples of this scenario include the partial data entry “lj” thathas no matches.

If multiple matches are found, the (No Suggestion) process event 750 isissued, which results in a transition back to the WAIT Partial Entrystate 220. An example of this transition and the resulting displayoccurs where a partial data entry “l” matches both the completed textitems “liver” and “ligament”.

The [Partial Entry] command 600, entered in the WAIT Partial Entry state520, can also consist of multiple characters. FIG. 3d illustrates thatif the partial data entry is “L”, the search of the completed data itemlist may result in finding the suggested completion “ligament” and“lumen”. If entering additional characters to distinguish a partial dataentry from multiple matches, i.e., the character “i” can be appended topartial data entry “l” in FIG. 3d to form partial data entry “li” andresulting eliminating “lumen” as a possible entry. This results in thefrom the ATTEMPT AutoComplete state 230. A (Suggested Completion)process event 730 is then issued and a transition to the DISPLAYCompletion state 540 occurs with the display of FIG. 3d being produced.It will be appreciated that the code space 301 a may also be populatedwith suggested codes and descriptors.

In contrast, if the character “o” is appended to the partial text entry“Ii”, partial text entry “lio” will be formed and a transition to theATTEMPT AutoComplete state 230 will occur. The search of the completedtext item list will result in finding no matches for partial text entry“lio”. The (No Completion) process event 740 will be issued and atransition to the DISABLE AutoComplete state 270 will occur.

In the WAIT Partial Entry state 220, the [Disable AutoComplete] command630 can also be entered. In an embodiment, the [Disable AutoComplete]command 630 may consist of moving the insertion point or cursor in theedit window. Other methods could also be utilized such as pressing afunction key. Entering this command causes a transition to the DISABLEAutoComplete state 270.

The final two commands that can be entered in the WAIT Partial Entrystate 220 are [Abort] 620 and [Accept] 610. Entering the [Abort] 620command results in a transition to the CLEAR AutoComplete state 260, inwhich the pre-edited contents of the alphanumeric character space willbe restored. The (Exit Edit) process event 760 will then be issued andthe edit mode 200 will be exited at point 295. Any partial data entriesdisplayed prior to the [Abort] 620 command will be erased. Entering the[Accept] command 610 causes a transition to the STORE AutoComplete state250 in which state the contents displayed in the alphanumeric characterspace are stored and the (Exit Edit) process event is issued to exit theedit mode 200 at point 295. In the preferred embodiment, an [Accept] 610can be issued by entering a carriage return or by using the key pad ormouse to change active cells. An [Abort] 620 can be issued by enteringthe [ESC] key. Other methods could also be used to implement thesecommands and are contemplated by the present invention.

The DISPLAY completion state 240, operates to display a suggestedcompletion in the alphanumeric character space. If the completion listis not fully generated, the (Build Next Level) background event 720 maybe issued as described above. While in the DISPLAY completion state 240,the user can enter the [Partial Entry] 600, [Accept] 610, [Abort] 620 or[Disable AutoComplete] 630 commands.

Entering [Partial Entry] 600 in the DISPLAY Completion state 240 causesa transition to the ATTEMPT AutoComplete state 530. The completed dataitem list will then be examined for a unique match of the partial entry.As a result of entering the ATTEMPT AutoComplete state 530 from theDISPLAY Completion state 540, two possible outcomes can be realized: (1)a unique match will be found or (2) no matches will be found.

Entering [Accept] 610 in the DISPLAY Completion state 540 causes atransition to the STORE AutoComplete state 250. Entering this state fromthe DISPLAY Completion state 240 will invoke a case conversion if one isrequired. Entering [Abort] 610 in the DISPLAY Completion state 540 willhave the same response as entering it in the WAIT Partial Entry state520 discussed above.

Entering the [Disable AutoComplete] command 630 in the DISPLAYcompletion state 240 will cause a transition to DISABLE AutoCompletestate 270. The contents of the alphanumeric character space will bemaintained; however, the portion of the text entry that had beendisplayed in reverse video will be changed to normal video to indicatethat AutoComplete is disabled.

The DISABLE AutoComplete state 270 operates to eliminate the overhead ofsearching through the completed data item list when it is known that amatch will not be found. For example, there are no matching entries inthe completed data item list for partial data entry “Lio”. Appendingadditional characters to the partial data entry “Lio” will not changethis situation. Thus, the DISABLE AutoComplete state 270 will allow theuser to continue entering partial entries without burdening theprocessing unit 414 of FIG. 4a with fruitless searches.

The DISABLE AutoComplete state 470 may also be entered if the completedtext item list is empty. This situation will occur when the first textitem in a new area is being entered or all other text items have beenfiltered out. In an embodiment which filters out numeric data items,editing a cell within a column of numbers will result in issuance of a(No Completion) 740 process event in the ATTEMPT AutoComplete state 230and a subsequent transition to the DISABLE AutoComplete state 270.

In the DISABLE AutoComplete state 270, an [Abort] 620, [Accept] 610, or[Enable

AutoComplete] 640 commands can be entered. The responses to the [Abort]620 and [Accept] 610 commands are identical to the responses generatedin the DISPLAY Completion state 240. Entering an [Enable AutoComplete]640 command will cause a transition to the WAIT Partial Entry state 220.In the preferred embodiment, the [Enable AutoComplete] 640 command cantake the form of back-spacing over or deleting the last enteredalphanumeric character(s) that caused the (No Completion) 240 processevent to be issued or returning the insertion point to the end of thepartial data entry. As an example, in the situation of a partial entry“lio” when the DISABLE AutoComplete state 270 is active. Backspacingover the letter “o” will cause the issuance of the [Enable AutoComplete]640 command and a transition to the WAIT Partial Entry state 220;however, the ATTEMPT AutoComplete state may optionally not be entereduntil a new partial text item is entered.

The CLEAR AutoComplete state 260 can be entered from the WAIT PartialEntry state, the DISPLAY Completion state 240, or the DISABLEAutoComplete state 270 upon the execution of the [Abort] 620 command.The [Abort] 620 command operates to erase the text that is currentlybeing displayed in the alphanumeric character space and then exiting theedit mode 200. In addition, the contents of the active cell prior toentering the edit mode 200 will be restored.

In the STORE AutoComplete state 250, the data being displayed in thealphanumeric character space is stored and the (Exit Edit) process event760 is executed to exit the edit mode 200 at point 295. This processoccurs independent of the prior state; however, when entering from theDISPLAY AutoComplete state 240, a case conversion may be performed onthe suggested completion.

FIG. 3f illustrates the entry (or selection) of the term “tornligament”. The entry causes a search of the codes for compatible codeand description entries. FIG. 3 f illustrates the insertion of suggestedmultiple CPT codes and descriptors. The health care provider may selectone or more of the suggested entries.

It will be appreciated that the display of the code descriptors willfacilitate the health care provider entry of a sufficiently clear andcomplete description of the diagnosis or treatment. The descriptors neednot be stored in the EHR code space but rather presented only during thedrafting of the EHR. Stated differently, the descriptors need not bestored as part of the text of the EHR. Further, the descriptorsappearing in the code space during drafting or entry of the patientdiagnosis, etc., can prompt the health care provider to provideadditional detail. For example, if the health care provider does notprovide whether the injured knee is the right or left, the displayeddescriptor will state the knee is unspecified. Similarly if the healthcare provider does not specify the ligament is injured, the descriptorwill state “ligament unspecified”, thus prompting the health careprovider to provide more specific information if possible. The corrector consistent use of descriptors, as suggested by the repeated displayof code descriptors, will facilitate correct or uniform terms todescribe a patient condition or diagnosis by health care providers. Thehealth care provider may select one of the suggested descriptor, therebyselecting the appropriate code for invoicing and EHR indexing. The useof uniform terms will facilitate the understanding of a subsequenthealth care provider reviewing the EHR or portion of the EHR provided inresponse to an information request. The enhanced uniform usage of termswill also facilitate the use of common terms in searching the patient'smedical history. This may also cause the code descriptors, establishedby various organizations, to be subject of editing and revisionsuggestions from the health care providers. This will clarify thedistinctions between the various codes and thereby reduce erroneousentries being created. This will facilitate both the billing function ofthe codes and the use of the codes for indexing of EHR and as a searchtool. The codes indexing a patient's EHR will allow for smart searching.It will not be necessary for the current health care provider to have toguess what medical terms have been used by a prior health care providerto describe the patient's condition of treatment.

In a synergistic fashion, the autocorrect and autocomplete functionsdiscussed in this disclosure will improve the descriptions entered bythe health care provider to improve the accuracy of the entered codes.In corresponding fashion, the code descriptors will suggest alternateand distinctive entries that may be used by the health care provider todescribe the diagnosis and/or treatment procedures. This can result inmore robust and meaningful records that will be available to subsequenthealth care providers. Stated differently, there will not be twoseparate languages used for recording a patient's health records, i.e.,a language used for determining correct billing and a language used byhealth care providers to describe the patient's condition (leading todiagnosis) or treatment.

Note further that the use of the codes as a search tool for a healthcare provider to promptly search and receive information of thepatient's medical history does not require that a central clearing houseor similar entity be created that coordinates search requests forpatient's prior medical history. The search request, specifying thepatient by common identity markers (name, date of birth, SSN, etc.) canbe simultaneously submitted electronically to multiple health careproviders. It will be appreciated that these requests will containevidence of patient's consent for disclosure of records.

Further, requests may be submitted through health insurance companies orother third party payors to be forwarded to other health care providersthat the insurance company records disclose have received insurancereimbursement for treatment of the identified patient and utilizing thesame or similar codes.

Case Conversion

The case conversion algorithm is a unique aspect of the AutoCompleteprocess and gives it the ability to handle data items with mixed upperand lower case characters. In general, the AutoComplete algorithm iscase insensitive during the data entry process. But, when a suggestedcompletion has been accepted, the AutoComplete process will adjust thecapitalization of the data item to be consistent with matching entries.The purpose behind the case conversion is to provide consistency for thetext items in the EHR. If a text item is being entered in lower case,and a matching completed text item is found that is in upper case, thenthe matching item will be displayed as a suggested completion. Theportion of the suggested completion that matches the partial text item(ignoring the capitalization) will be shown in normal video on thedisplay screen and in the capitalization that the partial text item wasentered. The portion of the suggested completion that does not includethe partial text item will be displayed in reverse video and in thecapitalization that corresponds with the suggested completion. Acceptingthe suggested completion will result in adjusting the case of thepartial entry to be the same as that of the suggested completion. But,if the user changes the insertion point or in some other way executes aDISABLE AutoComplete command 630, then accepting the text in thealphanumeric character space will result in maintaining the case of thecharacters as displayed in the alphanumeric character space.

Turning to FIG. 6, edit mode entrance point 205 indicates that the caseconversion algorithm becomes active when the edit mode 200 has beenentered for an alphanumeric character space. The process blocks shown inFIG. 6 are executed during various states of the AutoComplete process.Overall, the case conversion algorithm maintains an “AcceptedUnaltered”flag to indicate whether or not a case conversion should be performedupon exiting the edit mode 200. When the AcceptedUnaltered flag isequated to FALSE, as in process block 420, then the case conversion willnot be performed upon exiting the edit mode 200. Conversely, a value ofTRUE in the AcceptedUnaltered flag will cause a case conversion to beperformed. Thus, the AcceptedUnaltered flag is examined upon exiting theedit mode 200, to determine if a case conversion should be performed.

Decision block 410 illustrates that for each user command received,other than an [Abort] 420 or [Accept] 450, the THEN branch is followed.For each user command invoking the THEN branch of process block 410, theAcceptedUnaltered flag is set to FALSE as shown in process block 420. Ifthe user command results in producing a suggested completion (i.e., for[Partial Entry] 200 commands with unique matches), the THEN branch ofdecision block 430 will be followed and process block 440 will set theAcceptedUnaltered flag to TRUE. If the user command does not result infinding a suggested completion, then the ELSE branch of decision block430 is followed. In either of these cases, processing will return todecision block 410 and the next user command will be processed.

Once the [Abort] 620 or [Accept] 610 commands are received, the ELSEbranch of decision block 410 will be followed and decision block 450will be entered prior to exiting the edit mode. If the received usercommand was an [Accept] 450 command, then the AcceptedUnaltered flagwill be examined in decision block 460 to determine if a case conversionshould be performed. If the AcceptedUnaltered flag is equated to TRUE,process block 480 will be entered to perform the case conversion;however, if the AcceptedUnaltered flag is equated to FALSE, then thecurrent case displayed in the active cell will be maintained. In eithercase, the edit mode for the active cell will be exited at point 295. Insummary, whenever a partial entry results in producing a suggestedcompletion, a case conversion will occur upon a subsequent [Accept] 410command. If the user enters any command other than [Accept] 410, thenthe case conversion will be disabled until a subsequent suggestedcompletion is produced.

Similar to the above described autocomplete and autocorrect functions,the disclosure also teaches that text entries with thediagnosis/treatment/test space 302 a may trigger a suggested entry intothe code space. This step requires that there be a listing or vocabularyof code entries correlated with the text entry. Accordingly, entry of“torn ligament” in space 302 a of FIG. 3f , will prompt the entry ofcode numbers/letters related to the text “torn ligament” 301 a.

In an alternate embodiment, the entry of text indiagnosis/treatment/test space 302 a of “torn ligament” will trigger adisplay of a suggested diagnosis, etc., with the corresponding code. Inthis variation, it will be appreciated that the diagnosis text or nameentered into the code space 301 a is correlated with the diagnosisdescription appearing in 302 a. This embodiment has a vocabulary ofdiagnosis/treatment/test descriptors correlated with the possible textdescriptions entered by the health care provider. The code appears withthe descriptor. Stated differently, the alpha-numeric codes arecorrelated with possible text descriptions that may be entered by thehealth care provider.

It will be appreciated that in another embodiment, text descriptions ofdiagnosis/treatment/tests may be entered by speech recognitiontechnology. This allows the diagnosis/treatment/test entries may beentered by the health care provider's spoken words. This allows thehealth care provider to dictate his/her comments without turn away fromthe patient (as is required if the health care provider turns to typeinto a keyboard). One embodiment of speech recognition technology isdescribed in U.S. Pat. No. 8,670,979 issued to Thomas Robert Gruber etal. on Mar. 11, 2014 and which is incorporated by reference herein inits entirety. Other methods are included in the scope of thisapplication.

The device may also include a function to transcribe hand written textentered on the display screen with digital text.

Turning now to FIG. 7a , the detailed operation 210 of generating thecompleted text item list 300 is shown. The completed text item list usedin the AutoComplete process is a dynamic list (i.e., is built on the flyfor each data entry attempt). In contrast to a static lists, a dynamiclist does not require permanent memory resources. Therefore, once a textitem has been entered and accepted by the user, the memory occupied bythe completed text item list can be released and reallocated to otherresources. The trade off in using a dynamic list rather than a staticlist is the processing overhead required to generate a unique list uponeach entrance of the edit mode. In one embodiment, this processingoverhead is minimized by utilizing a tiered generation technique. Thistiered technique includes building a first text item list of entriesmost closely associated with the alphanumeric character space (currentor active cell) and, during idle time between user commands, augmentingthe list with other associated text items. This process will continueuntil the entire list has been completed. Thus, in this tieredtechnique, priority is given to user input, and text entry is notdelayed or “shuttered” while the text item list is being generated.

The first aspect in building the text item list is determining theparticular text items that are associated with the alphanumericcharacter space. The preferred embodiment utilizes a table determinationalgorithm to define the borders of a EHR. The algorithm defines a tableas a set of text items surrounded by “white space” or empty cells, i.e.a portion of the text space 302 a that may contain a single alphanumericcharacter or not, i.e., an empty cell. Ignoring certain exceptions suchas text boxes, table headings, picture objects, and print areadefinitions, this algorithm defines a rectangular border thatencompasses adjacent data items in the vertical horizontal and diagonaldirections.

The process of determining the data items that are associated with anactive cell (the portion of the text or code space that can accept asingle alphanumeric character) can be accomplished in several ways. Inthe most liberal approach, all of the data items entered into aspreadsheet and any associated sheets could be considered to beassociated with the active cell, and thus, become input into the dataitem list generation process. Although for some applications this may bea viable approach, the typical spreadsheet designer arranges associateddata into columns. Hence, in the more restrictive approach, only dataitems in the same column and same table (using the term table as definedby the above algorithm) would be considered to be associated with theactive cell. A further limitation would be to only include the block ofdata items that are in the same column as the active cell, encompass theactive cell, and are bordered by white space, i.e., a portion of thetext or code space that cannot accept an alphanumeric character.

The second aspect in building the text item list involves applyingfilters to the list of associated data items. Several filteringmechanisms can be employed. A first filtering mechanism includeslimiting the text items to alphabetical or alpha-numeric entries, andhence, excluding numeric entries. A second filtering mechanism is theelimination of duplicate data items from the text item list. Thus, if atext item has been entered in a column multiple times, sorting throughthe text item list will not be burdened by examining redundant textitems. Other filtering mechanisms can include (a) limiting the textitems to include only those items that have been entered more than once;(b) limiting the text items to only include data that conforms tocertain formatting restrictions; and (c) limiting the text items toentries that exceed a certain number of characters. In the preferredembodiment, the filtering mechanism is limited to the elimination ofduplicate text items.

FIGS. 7a-b illustrate a possible implementation of the algorithm togenerate a completion list. This algorithm is executed in the BUILDCompletion List state 300 shown in FIG. 7a . Entry block 205 of FIG. 5indicates that the generate completion list algorithm is invoked withinput parameters TIER and RANGE. The TIER parameter is used to identifywhich level of the completion list is to be generated. The purpose ofRANGE will be described later. In exit block 318 of FIG. 7a , thegenerate completion list algorithm returns the parameter STATUS. STATUSindicates whether the completed data item list has been fully generated(i.e., STATUS is equated to DONE) or if subsequent levels need to begenerated (i.e., STATUS is equated to TIER). This algorithm will beinvoked as many times as necessary until a completion list is generatedthat comprises all of the text items that are associated with thealphanumeric character space.

Continuing with FIG. 7a , in process block 302, the algorithm variablesand parameters are initialized. The variable CUR is defined as thelocation of the alphanumeric character space. The variables ABOVE andBELOW define the boundaries of the alphanumeric character spacesassociated with the active alphanumeric character space. These variablesare equated to the number of associated alphanumeric character spacesabove and below the current alphanumeric character space respectively.The variable J identifies the number of alphanumeric character spacesthat are to be included in the first tier or level 1 generation of thecompletion list. The variable K defines the number of alphanumericcharacter spaces included in subsequent tiers of the completion list. Inthe preferred embodiment the values of J and K are set to 50 and 20respectively; however, other values for these variables can be selectedand are contemplated by the present invention.

In decision block 304, the input parameter TIER is examined to determinewhich level of the completion list is being generated. If level 1 isbeing generated (TIER=1) then execution continues in process block 306.In this block two additional parameters are initialized. The STARTparameter is used to identify the location of the next associatedalphanumeric character space to be included in the completion list. Theparameter END is used to define the location of the last associatedalphanumeric character space to be included in the completion list forthe level being generated. In process block 306, these parameters areinitialized for the first level. Thus, in the preferred embodiment thefirst level will include associated alphanumeric character spaces 1 toJ, or the first 50 associated alphanumeric character spaces. If the TIERparameter is greater than 1 in decision block 304, then processingcontinues in block 308. If level 2 is being generated (TIER=2), processblock 308 equates START to J plus 1 (51 in the preferred embodiment) andEND is equated to START plus K. Thus, for level 2, the START and ENDvariables are set up so as to examine the next K alphanumeric characterspaces associated with the active alphanumeric character space (spaces51-70 in the preferred embodiment). For TIER N, space (N−2)*20+51 andthe following K−1 spaces will be added to the completed text item list.Upon completion of process block 306 or 308 process block 310 will beentered.

Process block 310 initializes the INDEX variable by equating it to thevalue of START. INDEX is used as a counter to indicate when all of thespaces for the current level have been read and is also used as apointer in the list of completed text items to identify the location tostore the next text item. Input parameter RANGE is used as a pointer toindicate the distance above and below the active character space wherethe next text item is to be retrieved. When entering edit mode for theactive character, the RANGE variable is equated to 1. The text characterspaces immediately above and below the active space are at RANGE 1. Thenext two spaces above and below the active space are at RANGE 2. Thus,as text items are retrieved from associated spaces, the RANGE variableis incremented. The value of RANGE must be retained between subsequentcalls to the BUILD Completion List algorithm.

Process block 312 invokes the Retrieve Tier of Completed Text Itemsroutine shown in FIG. 7b . This routine utilizes the variables RANGE,INDEX, ABOVE, BELOW, END, CUR, and STATUS in retrieving and building thenext level of the completion list. Process block 314 applies theappropriate filters to the completed text item list. Process block 316will sort the new filtered completed text item list in alphabeticalorder. Finally, exit block 318 returns the STATUS variable to thecalling routine.

Turning to FIG. 7b , the details of process block 312 in FIG. 7a areprovided. Entrance block 320 in FIG. 7b indicates the starting point ofthe routine. In process block 322 a check is performed to determine ifall of the text items for the level being generated have been retrieved.This is accomplished by verifying that RANGE is less than or equal toABOVE or BELOW and that INDEX is less than or equal to END. The programvariables for level 1 will be initialized as follows:

-   -   a. START=1        -   END=50        -   ABOVE=1 (includes text character space 328)        -   BELOW=1 (and comprises text character space 326)        -   RANGE=1        -   INDEX=1

Continuing with the example, decision block 322 in FIG. 7b determinesthat RANGE (equated to 1) is equal to ABOVE and less than BELOW, andthat INDEX is less than END. Therefore, the THEN branch of decisionblock 322 will be followed and decision block 324 will be entered. Inthe THEN branch of decision block 322, RANGE is examined in comparisonto ABOVE and BELOW to determine which associated text character spacesshould be selected. The basic premises of the algorithm is to select thenext closest space to the active alphanumeric character space, givingpreference to spaces above the active space. For instance, when buildinga level of associated text items, if there are spaces above and belowthe active text character space, they are selected by alternatingbetween the space above and the space below the active alphanumericcharacter space. In some instances, there will be character spaces abovethe active alphanumeric character space but no text character spacesbelow the active alphanumeric character space or vice versa. In thiscase, only the character spaces above or below the active text characterspace are selected. Thus, if the bottom text character space in a columnis being edited, then the J text character spaces above the activealphanumeric character space will be selected in the first level.Alternatively, if the text character space is being edited, then the Jtext character spaces below the active alphanumeric character space willbe selected.

In process block 324, if RANGE is less than or equal to ABOVE, thenthere are associated text character spaces above the active alphanumericcharacter space. Execution then continues in process block 326 where thecontents of the text character space at the location of the activealphanumeric character space plus RANGE is loaded into the completedtext item list at the location of INDEX. In addition, INDEX isincremented by 1. In decision block 324, if RANGE is greater than ABOVE,then there are no associated text character spaces above the activealphanumeric character space and the ELSE branch will be followed.Whether or not process block 326 is executed, processing will continueat decision block 328. In decision block 328, if RANGE is less than orequal to BELOW, then there are associated text character spaces belowthe active alphanumeric character space. Execution then continues inprocess block 330 where the contents of the text character space at thelocation of the active alphanumeric character space minus RANGE isloaded in to the completed text item list at the location of INDEX. Inaddition, INDEX is incremented by 1. In decision block 328, if the valueof RANGE is found to be greater than BELOW, then there are no associatedtext character space below the active cell and the ELSE branch will befollowed. Whether or not process block 330 is executed, processing willcontinue in process block 336. In process block 336, RANGE isincremented by 1 and processing returns to decision block 322.

Therefore, the overall effect of executing the THEN branch of decisionblock 322 is to obtain the next two completed text items associated withthe active letter string. In some instances, only one text data itemwill be retrieved. This will be the case when there are no associatedtext character spaces either above or below the active alphanumericcharacter space text string.

For example, after the first execution of the THEN branch of decisionblock 322, the variables will be set to the following values:

-   -   a. START=1        -   END=50        -   ABOVE=1        -   BELOW=11        -   RANGE=2        -   INDEX=3

In decision block 322 for the current example, RANGE is no longer lessthan or equal to ABOVE. But, RANGE is less than BELOW and INDEX is lessthan END. Therefore, processing will continue to execute through theTHEN branch of decision block 322 and returning to process block 322until either (1) RANGE is greater than both ABOVE and BELOW, or (2)INDEX is greater than END. In the first case, the list of completed textitems is fully generated. Thus, in decision block 332, INDEX will beless than END causing process block 334 to be executed, equating STATUSto DONE. In the second case, additional levels must be generated. Thus,in decision block 332, INDEX will be greater than END resulting inreturning STATUS equated to the value of TIER or the level that wasgenerated.

Referring now to FIG. 8, the AutoComplete algorithm invoked in theATTEMPT AutoComplete state 230 (shown in FIG. 5) is illustrated as aflow diagram. The ATTEMPT AutoComplete state 530 is entered from theWAIT Partial Entry state 520 or the DISPLAY Completion state 540 uponproviding a partial data entry.

Entrance block 500 in FIG. 8 illustrates that the AutoComplete algorithmuses input parameter [Partial Entry] 520. In process block 210, thecompleted data item list is searched for items that match [PartialEntry]. The searching process can be accomplished using a binary search,sequential search, or various other searching techniques. If at leastone match is found, the THEN branch of decision block 530 will befollowed and decision block 550 will be entered. At decision block 550,if more than one match has been identified in the completed text itemlist, the THEN branch of decision block 550 will be followed and processblock 520 will be entered. In block 520 the (No Suggestion) processevent 750 will be issued, and a transition to the WAIT partial entrystate 520 will occur. Returning to decision block 550, if only one matchwas identified in the completed data item list, the ELSE branch ofdecision block 550 will be followed and process block 540 will beentered. In process block 540, the (Suggested Completion) process event730 will be executed and a transition to the display completion state540 will occur.

Returning to decision block 530, if no matches are found in thecompleted data item list, the ELSE branch of decision block 530 will befollowed and process block 570 will be entered. In process block 570, a(No Completion) process command 740 will be executed and a transition toDISABLE AutoComplete state 270 will occur. Block 560 in FIG. 8 will thenbe entered and the AutoComplete algorithm will be exited.

From the foregoing description, it will be appreciated that the presentdisclosure provides a method to improve the efficiency and reliabilityof text entry in a EHR record by providing the ability for an automaticcompletion process utilizing a list of completed text items comprised oftext associated with the medical diagnosis, treatment or test item beingentered into the EHR. The disclosure also creates improved efficiencyand reliability in the diagnosis, treatment and test codes associatedwith the text entry of the health care provider.

The foregoing method of the present disclosure may be convenientlyimplemented in one or more program modules. No particular programminglanguage has been indicated for carrying out the various tasks describedabove because it is considered that the operation, steps, and proceduresdescribed in the specification and illustrated in the accompanyingdrawings are sufficiently disclosed to permit one of ordinary skill inthe art to practice the instant invention. Moreover, in view of the manydifferent types of computers and program modules that can be used topractice the instant invention, it is not practical to provide arepresentative example of a computer program that would be applicable tothese many different systems. Each user of a particular computer wouldbe aware of the language and tools which are more useful for that user'sneeds and purposes to implement the instant invention.

The above described features of the present disclosure have beendescribed in relation to particular embodiments which are intended inall respects to be illustrative rather than restrictive. Those skilledin the art will understand that the principles of the present disclosuremay be applied to, and embodied in, various program modules forexecution on differing types of computers regardless of databaseapplication.

Alternative embodiments will become apparent to those skilled in the artto which the present disclosure pertains without departing from itsspirit and scope. Accordingly, the scope of the present disclosure isdescribed by the appended claims and supported by the foregoingdescription.

The population of the code space with one or more suggested codes isachieved by creating a data base of the codes and each code'sdescriptor. When the descriptor is entered in FIG. 3a into the textspace 302 a, the corresponding code is entered in code space 301 a.

As described above, this disclosure teaches the health care providerentering diagnostic notes etc., electronically into a device. Thedisclosure facilitates this entry of data by auto-correct features, etc.The disclosure also teaches display of suggested codes based upon thetext of the entered data. This step may include matching of entered textdata with the text of code descriptors. However the disclosure includesdirect matching of alphanumeric codes to the healthcare provider'sentered text. This disclosure teaches the following steps as oneembodiment of populating the code space with suggested codes and thehealth care provider enters the description of the diagnosis ortreatment, etc. First, the correlation of the data entry with allpossible applicable codes. In a simple embodiment, the code space wouldbecome populated with all codes containing “knee” in the descriptor. Asthe health care provider added additional text, e.g., “torn ligament”,the codes pertaining to “sprains or tearing of knee ligament” would besubstituted into the code space. In other embodiments, the program couldenter all codes that were classified and correlated as applicable totorn knee ligaments. This could be further expanded to applicationsutilizing artificial intelligence algorithms.

Such algorithm would create a dynamic completion list, in contrast tosolely utilizing pre-defined values. The completion list is generatedfrom a set of data within the database that is associated with the dataitem being entered, and reflects the status of the database at the timethe data item is being entered. The benefits associated with this aspectof the invention include: (i) providing a completed text item list thatis automatically updated to reflect the current contents of thedatabase; (ii) providing a completed text item list that is notencumbered by extraneous data entries that have no relationship with theitem being entered; and (iii) providing an automatic completion featurethat is not restricted to the use of a limited list of possiblecompletions (i.e., a predefined data set).

A unique aspect of the generation process includes defining which entrytext items or descriptions entered into the text space (diagnosis,treatment, test) 302 a are associated with the code being suggested 301a. In the context of a generic database, the present invention providesseveral methods to perform this process. Generally, text entry items,e.g. diagnosis or procedure descriptions, that fall within the samecategory or a similar category to the code item being suggested areconsidered to be associated text items. Therefore, an advantage of thepresent disclosure is the ability to define which alphanumeric entrieswithin a code database are related to a text item being entered by thehealth care provider, to generate a list of suggested codes based onthese associated diagnosis or treatment data entries, and to provide adynamic completion code list which tracks the actual contents of thediagnosis or treatment, etc.

Electronic health records (EHR) track patient health care informationover time. Further, the EHR records can easily identify patients due forpreventive screenings or checkups. Also, the records can check thepatient's health conforming to certain parameters such as blood pressurereadings or vaccinations. Overall, the EHR can serve to monitor andimprove overall quality of patient care. EHRs may focus on the totalhealth of the patient, i.e., going beyond standard clinical datacollection of care within a single health care provider's office, etc.EHRs are designed to share information with other health care providers,such as laboratories and specialists, so that the EHRs containinformation from all the clinicians involved in the patient's care. Anelectronic health record (EHR) is created, managed, and consulted byauthorized clinicians and staff across more than one healthcareorganization. The EHR is formatted to be used both intramurally (withinthe “walls” of a single health care provider similar to an electronicmedical record (EMR) and to be used inter-mural fashion, i.e., sharedand accessible to multiple authorized health care providers outside ofthe wall of a single institution.

EHR Search Request

Search Request lnitation

FIG. 12a illustrates another embodiment of the device and particularlythe display screen 500. The request for a record search may be activatedby entering the information prompted on the display screen 500 indicatedon the data entry form (FIG. 12a ) and pressing the search key 531 ofthe user input component 500. In other embodiments, one or more radiobuttons may be used. As in FIGS. 3a-3g , data can be entered into aninput space 502 a 502 b of the display with suggested codes appearing incode space 501 a 501 b. The patient identification information may beentered 520. Also the user (clinician) entering the data may beidentified 520. The user may be subject to pre authorization oridentification. This authorization or identification standards may besubject of procedures as discussed in relation to FIGS. 18 and 19 infra.

Note that the device illustrated in FIG. 12a allows the user to initiatea search 530 531 of the patient specific EHR. The scope of the searchmay be specified to be broad, wherein perhaps all related search codesor search words may be use as supplemented by machine learning or thesearch be customized or limited to certain key phrases or codes. Thecontents of the display screen may be entered or integrated into thepatient specific EHR by activation of the “enter” key 531 b.

Note further that in one embodiment of the device 500, eachdiagnosis/treatment/test data entry space 502 a 502 b and each codespace 501 a 501 b contains a scroll bar 505 or similar device that allowentry and view of content within a space larger than the specific sizeof the screen display, i.e., 502 a.

FIG. 12b illustrates another embodiment of the device and display screen550. The device allows searching 570 of multiple data entries 590.Editing of the data entry may be performed 540 541. A search 599 may beinitiated from the device and data entered 551 into the patient EHR.Note further that data entries may be designated by user's estimation ofrelevance or accuracy 520. As before, suggested codes 585 relevant tothe entry of data 590 may be displayed. User/reviewer supplementalnotations can be recorded and displayed 591.

It will be appreciated that the user may, after review of initial searchresults, modify the code entries or diagnosis notations to conduct afollow-on search. This follow-on may search, if initiated within aspecified time, may avoid the clinician from re-initiating theauthentication procedures or “log-in” as described infra.

The current health care provider can access the patient's EHR by severalmethods. The health care provider can create a search request,identifying the requestor, the patient name DOB, social security number,and if applicable, a hospital assigned ID number or similar. Thereshould be include some type of security such as encryption to assurepatient confidentiality is not breached. See the discussion below.

Also, the Health Insurance Portability and Accountability Act (HIPAA)does not require a patient's consent be obtained by a health careprovider for disclosure of records for continuing medical treatment.Therefore consent should not be required to allow the entity havingcustody of the past EHR records to furnish requested information to thecurrent health care provider. However, the requesting health careprovider may want to confirm that the information is being requested forthe purpose of furnishing health care services to the patient. (It willbe appreciated that specific authorization is required by HIPAA to beobtained from the patient to disclose the information for purposes otherthan treatment, billing or insurance purposes.)

A further goal is to minimize the time and effort required of a currenthealth care provider to obtain the past diagnosis/treatment/test EHRrecords for a patient relative to the current diagnosis (or for theprocess of establishing or confirming a diagnosis or treatment plan).This may be accomplished in several ways, including but not limited tothe current health care provider being provided an option to searchwithin a patient's EHR of past medical events during the diagnosingprocess. It will be appreciated that the patient may not be able toidentify past health care providers or provide reliable dates as to whenthe past treatment was furnished. Also the current health care providermay search within the identified EHR for a past record of symptoms orconditions now observed in the patient. The health care provider mayenter text of observed symptoms/conditions.

In an embodiment of the disclosure, the health care provider may entercodes applicable to allergies to medications. In yet another embodiment,the health care provider could enter codes applicable to specificexisting medical treatments or medications such as cardiac stents,valves or other items such as treatment with blood thinners. These couldbe a regimen of codes that could be proactively searched at the start ofthe patient encounter. Also the patient's allergy history can besearched along with the patient's current regimen of medications.

The health care provider may receive suggested codes and codedescriptors from the system subject of this disclosure. The suggestionsarise from machine learning as well as word searches of the text in realtime. The health care provider may continue with entering text,modifying text in response to the prompted code/code descriptors orselecting at least one of the prompted codes. In one embodiment, thehealth care provider may be provided with the option to search for thepatient's EHR and to request information relevant or responsive to theprompted codes.

FIG. 12c provides a partial overview of some embodiments of the deviceand method. The user 210 can input data and receive search informationvia a user interface 1011. This interface may include the programed CPUand the display screen discussed above. User may enter text notationsand optional search requests 591 430. In the disclosed embodiment, thesystem utilizes a Device Manager 310 that may provide access to thepatient EHR residing in a File Storage/Document Collection 120. Thesearch results, initiated via 951, may be received via the display 590of “Review of Search Text & Suggested or Learned Codes”. Also note thatthe user coding decision 555, based upon suggested codes responsive tothe user's text 591, are inputted to the Document Manager 310 and EHRrepository 120. The search request data 430 is also accessible to theuser via the Document Manager 310

EHR Security

It is yet another goal of the disclosure to provide security to thepatient's EHR, i.e., ensure that the contents of the EHR are nottampered with nor that there be any unauthorized disclosure of the EHRcontents. This may require that the health care provider be identifiedas a person or entity authorized to have access to the patient's EHRprior to the health care provider being allowed to create data orinformation that will be added to the patient's EHR. Therefore it is agoal of this disclosure to provide an authentication process. This maybe particularly applicable where the health care provider is a member ofa larger entity, e.g., hospital, or network of entities.

In one embodiment, the health care provider may be subject to a twofactor authorization process wherein encryption may be required as onestep and a second step requiring authentication by entering a user nameand password. As discussed in further detail below, this disclosureincludes teaching of an EHR electronic data entry form for entry of thetext notes of observations and diagnosis. The electronic data entry formrequires identification of the patient as well as the identity andauthorization of the health care provider. The form also allows theentered data to be instantly converted to an EHR search request withoutthe health care provider having to duplicate entry of any information.The EHR search request form can be auto-populated with the informationappearing on the EHR data entry form. See FIG. 14a 5 a.

This feature will allow the search for past diagnoses and treatmentrelevant to the current observed patient conditions to be initiatedprior to completion of the diagnosis and formulation of a treatment planor ordering of tests. Also the ability to auto populate the searchrequest form avoids additional time as well as transcription errors.

Data Entry & Code Protocol Integration into EHR

The Applicant's disclosure allows the machine learning tochange/amend/supplement the descriptors to encompass the health careprovider's entry. The process, under taken by machine or active learningfacilitates the translation of the health care provider's text into theuniversally understood common language. The amended identifier willreduce the number of “partial matches”, thus making the health careprovider's job of entering appropriate codes substantially easier.

Further, this disclosure includes embodiments wherein the code selectedby the health care provider is imbedded into the EHR. The disclosureincludes machine learning and resulting modification of the codedescriptors (becoming code identifiers) to expand the identifier to moreclosely match or encompass the text used by the health care provider.

Further, the active machine learning subject of this disclosure attemptsto understand the health care provider's text entry and correlate it toone or more alternate code protocol descriptors. The object is to getthe health care provider's feedback in real time and the modify or amendthe descriptors so that the text entries are correlated to the codedescriptors and vice versa. This modification is achieved throughmachine learning.

The disclosure also learns from the selection of the code, presumablybased on the code descriptor (where the code descriptor is part of theoriginal code protocol) or later created code identifier. The healthcare provider creates an EHR entry using his/her own text language todescribe the condition, etc. The machine learning system evaluates thetext.

For example, the health care provider may describe a patient conditionin multiple different ways:

-   -   a. “Complaint of knee pain.”    -   b. “Patient complains of pain in the knee.”    -   c. “Patient can't run due to pain in the knee”    -   d. “Patient can't run due to pain in his knee.”    -   e. “The patient states his knee is sore after running and it        hurts to stand from a sitting position.”    -   f. “Complaint of pain in his knee when he rotates his foot (and        ankle).”    -   g. “Patient complains that his knee hurts when he bends his leg        (at the knee).”    -   h. “Patient's knee hurts when he stands an places weight on his        knee.”    -   i. “Patient's knee hurts when he climbs stairs.”    -   j. “Patient knee is swollen on one side and shows edema”    -   k. “Patient's knee is sore and red. Also tender on left side.”

At initiation of the system, the disclosure may evaluate the text entryto identify the subject matter, i.e., knee and the adjective used tofurther describe the knee. The disclosure may perform a key word searchbased upon:

-   -   i. Location of the event/complaint/symptom etc., Here “knee”    -   ii. and (initially at startup) suggests codes and code        descriptors.    -   iii. Symptom complained of, here “pain”, “sore” “hurt” &        “tender”    -   iv. Symptoms observed: redness, swelling, edema    -   v. Other factors can be searched such as “is this the first time        of complaint” See ICD descriptors.    -   vi. Duration (see above)

The system may perform multiple key word searches of multiple codeprotocol (or at least one code protocol selected by the health careprovider or health care institution). This search may produce multiplesuggested codes.

In one embodiment, if the health care provider simply enters “knee”, thesystem may respond with a display of “Too broad” in the window or paneused to display suggested codes. This may prompt the health careprovider to further define the symptoms.

In one embodiment, the search may be “knee pain”, “pain in knee”,

-   -   i. “swollen knee” “knee swollen”, “knee swelling”    -   ii. “hurt knee”, “knee hurt”    -   iii. “knee edema”

The search results for ICD-10 code protocol for each search are:

-   -   i. “knee”, “knee pain”, “pain in knee”,        -   1. “Complete matches”        -   2. M25.56 Pain in knee        -   3. M25.561 Pain in right knee        -   4. M25.562 Pain in left knee        -   5. M25.569 Pain in unspecified knee        -   6. T84.84 Pain due to internal orthopedic prosthetic            devices, implants and grafts        -   7. M22.2X9 Patellofemoral disorders, unspecified knee        -   8. “Partial matches” Selected (approximately 150 responses            displayed)        -   9. T85.840 Pain due to nervous system prosthetic devices,            implants and grafts        -   10. T85.848 Pain due to other internal prosthetic devices,            implants and grafts        -   11. A18.02 Tuberculous arthritis of other joints        -   12. M17 Osteoarthritis of knee        -   13. M24.56 Contracture, knee        -   14. M24.66 Ankylosis, knee        -   15. M25.16 Fistula, knee        -   16. M25.46 Effusion, knee        -   17. M25.76 Osteophyte, knee        -   18. M67.46 Ganglion, knee        -   19. M94.26 Chondromalacia, knee

Search “swollen knee” “knee swollen”, “knee swelling”

-   -   1. “Complete matches”    -   2. M25.469 Effusion, unspecified knee    -   3. “Partial matches”    -   4. M17 Osteoarthritis of knee    -   5. M24.56 Contracture, knee    -   6. M24.561 Contracture, right knee    -   7. M24.562 Contracture, left knee    -   8. M24.569 Contracture, unspecified knee    -   9. M24.66 Ankylosis, knee        -   a. M24.661 Ankylosis, right knee        -   b. M24.662 Ankylosis, left knee        -   c. M24.669 Ankylosis, unspecified knee    -   10. M25.06 Hemarthrosis, knee        -   a. M25.061 Hemarthrosis, right knee        -   b. M25.062 Hemarthrosis, left knee        -   c. M25.069 Hemarthrosis, unspecified knee    -   11. M25.16 Fistula, knee        -   a. M25.161 Fistula right knee        -   b. M25.162 Fistula left knee        -   c. M25.169 Fistula unspecified knee    -   12. M25.46 Effusion, knee        -   a. M25.461 Effusion right knee        -   b. M25.462 Effusion left knee    -   13. M25.76 Osteophyte, knee        -   a. M25.761 Osteophyte, right knee        -   b. M25.762 Osteophyte, left knee        -   c. M25.769 Osteophyte, unspecified knee    -   14. M67.46 Ganglion, knee        -   a. M67.461 Ganglion, right knee        -   b. M67.462 Ganglion, left knee        -   c. M67.469 Ganglion, unspecified knee    -   15. M94.26 Chondromalacia, knee        -   a. M94.261 Chondromalacia, right knee        -   b. M94.262 Chondromalacia, left knee        -   c. M94.269 Chondromalacia, unspecified knee    -   16. M179 Osteoarthritis of knee, unspecified    -   17. S80.21 Abrasion of knee        -   a. S80.211A Abrasion, right knee, initial encounter        -   b. S80.211D Abrasion, right knee, subsequent encounter        -   c. S80.2115 Abrasion, right knee, sequela        -   d. S80.212A Abrasion, left knee, initial encounter        -   e. S80.212D Abrasion, left knee, subsequent encounter        -   f. S80.212S Abrasion, left knee, sequela        -   g. S80.219A Abrasion, unspecified knee, initial encounter        -   h. S80.219D Abrasion, unspecified knee, subsequent encounter        -   i. S80.219S Abrasion, unspecified knee, sequela    -   18. S80-S589 Injuries to the knee and lower leg    -   19. S80 Superficial injury of knee and lower leg    -   20. S80.0 Contusion of knee    -   21. S81 Open wound of knee and lower leg    -   22. M00.06 Staphylococcal arthritis, knee    -   23. M00.16 Pneumococcal arthritis, knee    -   24. M02.16 Postdysenteric arthropathy, knee    -   25. M02.26 Postimmunization arthropathy, knee    -   26. M02.36 Reiter's disease, knee    -   27. M05.06 Felty's syndrome, knee    -   28. M06.26 Rheumatoid bursitis, knee    -   29. M06.36 Rheumatoid nodule, knee    -   30. M07.66 Enteropathic arthropathies, knee    -   31. M10.06 Idiopathic gout knee    -   32. M10.16 Lead-induced gout, knee    -   33. M10.26 Drug-induced gout, knee    -   34. M11.16 Familial chondrocalcinosis, knee    -   35. M11.26 Other chondrocalcinosis, knee    -   36. M12.16 Kaschin-Beck disease, knee    -   37. M12.36 Palindromic rheumatism, knee        -   a. M12.361 Palindromic rheumatism right knee        -   b. M12.362 Palindromic rheumatism left knee        -   c. M12.369 Palindromic rheumatism unspecified knee    -   38. M12.46 Intermittent hydrarthrosis, knee        -   a. M12.461 Intermittent hydarthrosis, right knee        -   b. M12.462 Intermittent hydarthrosis, left knee    -   39. M12.56 Traumatic arthopathy, knee        -   a. M12.562 Traumatic arthopathy left knee        -   b. M12.569    -   40. M14.66 Charcot's joint, knee        -   a. M14.661 Charcot's joint, right knee        -   b. M14.662        -   c. M14.669    -   41. M21.26 Flexion deformity, knee        -   a. M21.261        -   b. M21.262        -   c. M21.269    -   42. M23 Internal derangement of knee    -   43. M24.46 Recurrent dislocation, knee        -   a. M24.461 Recurrent dislocation, right knee        -   b. M24.462. Recurrent dislocation, left knee    -   44. M25.26 Flail joint, knee        -   a. M25.261 Flail joint, right knee        -   b. M25.261 Flail joint, left knee        -   c. M25.269. Flail joint unspecified knee    -   45. M25.36 Other instability, knee        -   a. M25.369 Other instability, unspecified knee    -   46. M25.56 Pain in knee        -   a. M25.561 Pain in right knee        -   b. M25.562 Pain in left knee    -   47. M25.66 Stiffness of knee, not elsewhere classified        -   a. M25.662 Stiffness of left knee        -   b. M25.669 Stiffness of knee, not elsewhere classified    -   48. M67.36 Transient synovitis, knee        -   a. M67,361 Transient synovitis, right knee        -   b. M67.362 Transient synovitis, left knee        -   c. M67.369 Transient synovitis, unspecified knee    -   49. M93.26 Osteochondritis dissecans knee        -   a. M22.2X1 Patellofemoral disorders, right knee        -   b. M22.2X2 Patellofemoral disorders, left knee        -   c. M22.2X9 Patellofemoral disorders, unspecified knee    -   50. M22.40 Chondromalacia patellae, unspecified knee        -   a. M22.41 Chondromalacia patellae right knee        -   b. M22.42 Chondromalacia patellae left knee    -   51. M23.40 Loose body in knee, unspecified knee        -   a. M23.41 Loose body in knee, right knee        -   b. M23.42 Loose body in knee, left knee    -   52. M23.52 Chronic instability of knee, left knee    -   53. M67.50 Plica syndrome, unspecified knee

In view of the size of responsive entries for search terms “swollenknee” “knee swollen”, “knee swelling”, the coding system may display“Too Broad”. This may prompt further defining text to be entered by thehealth care provider. Upon the health care provider's modification ornarrowing of the entry, the search of appropriate codes may beautomatically repeated. Note that this activity can occur during thepatient encounter. Therefore code entries can be precisely defined. Thisis in contrast to current practice wherein coding occurs “after thefact” and may be performed by a third party interpreting the health careprovider's cryptic notes.

In another example:

-   -   i. Search “hurt knee”, “knee hurt”        -   1. No complete match, approximately 150 partial matches.            List of partial matches is the same as results for “swollen            knee”    -   ii. Again, due to the large number of responsive partial        matches, the system may again respond with “Too Broad”.

Search “knee edema

-   -   1. No complete matches    -   2. Partial matches    -   3. M17 Osteoarthritis of knee        -   a. M17.9 Osteoarthritis of knee unspecified    -   4. M24.56 Contracture, knee        -   a. M24.561 Contracture, right knee        -   b. M24.562 Contracture, left knee        -   c. M24.569 Contracture, unspecified knee    -   5. M24.66 Ankylosis, knee        -   a. M24.661 Ankylosis right knee        -   b. M24.662 Ankylosis left knee        -   c. M24.669 Ankylosis unspecified knee    -   6. M25.06 Hemarthrosis, knee        -   a. M25.061 Hemarthrosis, right knee        -   b. M25.062 Hemarthrosis, left knee        -   c. M25.069 Hemarthrosis, unspecified knee    -   7. M25.16 Fistula, knee        -   a. M25.161 Fistula, right knee        -   b. M25.162 Fistula, left knee        -   c. M25.169 Fistula, unspecified knee    -   8. M25.46 Effusion, knee        -   a. M25.461 Effusion, right knee        -   b. M25.462 Effusion, left knee        -   c. M25.469 Effusion, unspecified knee    -   9. M25.76 Osteophyte, knee        -   a. M25.761 Osteophyte, right knee        -   b. M25.762 Osteophyte, left knee        -   c. M25.769 Osteophyte, unspecified knee    -   10. M67.46 Ganglion, knee        -   a. M67.461 Ganglion, right knee        -   b. M67.462 Ganglion, left knee        -   c. M67.469 Ganglion, unspecified knee    -   11. M94.26 Chondromalacia, knee        -   a. M94.261 Chondromalacia, right knee        -   b. M94.262 Chondromalacia, left knee        -   c. M94.269 Chondromalacia, unspecified knee

In this instance, the system may only display the general category(class) for M17 “Osteoarthritis of knee”, M24.56 “Contracture, knee”,M24.66 “Ankylosis, knee”, M25.06 “Hemarthrosis, knee”, etc.

Clinician Specification & Selection

The health care provider may be prompted to specify left or right knee,etc. This would disclose the sub-class. The health care provider may beprompted to initiate a search using codes M17, M24, M25, M67 or M94.

FIG. 9 represents a conceptual overview of a classification system 900.The classification system utilizes machine learning and conducts keyword searches. The EHR Data Entry and Record Search Request 920 (SeeFIG. 12a ) may be any health care or treatment information identifiableto a single patient that can be stored in any electronic formatincluding a word-processing file, spreadsheet, email, text message,contact list, calendar entry, HTML file, image file, video file, sourcecode, object code, post-script file or a digital version of a physicaldocument. An EHR data entry form (See FIG. 12a ) may be used toelectronically create EHR data information pertaining to an identifiablepatient and an identifiable health event, e.g., an ER visit or annualphysical, etc. EHR data may also be handwritten text information,videos, images, etc. that are recorded and transportable/displayable inelectronic format. The document collection can comprise multiple sourcesof EHR data stored in separate locations. It may also comprise adatabase. The document collection may also refer to an EHR data entryform.

Continuing with FIG. 9, the classification system 900 is utilized byeach code protocol to organize the different diagnosis/treatment/textprocedures. For example, diagnoses pertaining to the knee will be in oneclass with numerous subclasses (sub categories). Each class 930 andsubclass 940 will be assigned a different alphanumeric code. Thestructure of the code may disclose its class and subclass, etc. It willbe appreciated that each subclass may also have additional subclasses,thus creating a multi-level hierarchy of classes and subclasses. Thehierarchy may be disclosed by the alphanumeric code.

Each class, subclass, and sub-subclass will comprise a distinct code andcode descriptor.

A medical issue described in the EHR data entry form 920 may beclassified as a member of any number of classes 930 or subclasses 940defined for a classification problem. For example, class 1 mightrepresent the set of medical issues related to a patient's knee(s),while class 2 might represent a set of medical issues related to thepelvis, femur and/or hip joint, all as described in the health careprovider's text data entry. A subclass 1 of class 1 might furtherclassify medical issues as potentially relevant to the meniscus, whilesubclass 2 of class 1 might refer to medical issues related to theligaments of the knee. There may yet be a third subclass (not shown)related to issues of the knee cap (patella). A further sub-subclassdistinguishing between the left knee and the right knee. A yet furthersub-subclass may pertain to whether this is the first or a subsequentissue pertaining to the knee.

It will be appreciated that in some instances, EHR data not previouslyindexed by the use of a coding protocol as taught by this disclosure,may be indexed utilizing the classification system 900 as shown in FIG.9 in response to a search request of a health care provider. Theclassification system may contain one or more optical character readers(OCR). After such classification step is performed, the now indexed datamay be parsed for codes and text responsive to the search request.

The EHR data may be indexed utilizing keyword techniques to match thetext with the code descriptors and code identifiers. This may requiresegregation of terms as nouns comprising locations such arm, elbow,wrist, femur, tibia, pelvis noted in the text of the EHR record withcodes containing these locations words in the code descriptor. In someinstances, heath care records that have been previously coded forbilling purposes may be utilized as a resource for EHR codeclassification.

In FIG. 10 illustrates one embodiment of a system of this disclosure.The system may be comprised of one or more devices 1020. Each device hasan input device 1028 that is accessed by a health care provider 1010.The health care provider enters text describing the examination of apatient. In one example, the text entry includes a diagnosis of thepatient's health condition. The entered text is displayed 1022 for theprovider. The text entry is also entered in the processor 1024. Theprocessor includes the one or more code protocols. In response to thetext entry, the processor suggests and displays at least one code entryfrom a protocol. The suggested code is selected by the content of thehealth care provider's text entry, e.g., diagnosis. The device includesa storage device 1026. It may be a transitory of volatile storage. Thehealth care provider may accept at least one of the suggested codeentries. The text entry and the accepted code(s) are stored in memory.The health care provider may initiate the search function from thedevice 1020.

It will be appreciated that the disclosure incorporates the text of thehealth care provider's notations, along with the related code entry. Inan embodiment, the EHR entry may also include the code descriptor oridentifier. Other prior art systems only incorporate “extracted facts”into the EHR. Utilizing the “extract facts” method, the textdescriptions of the prior art systems may be redacted from the fullentered text into an abbreviated structured format. This can eliminatenuances or significant details that were contained in the health careprovider's full and complete notation. In a preferred embodiment of theApplicant's disclosure, such detail remains accessible as part of theEHR. This disclosure includes retaining the health care provider'snotations in a non-abbreviated and non-structured format.

It will be further appreciated that the health care provider may utilizeterminology (slang) that is not included in the protocol of the textdescriptors. However, the input device display will alert the healthcare provider of the discrepancy when no or inapplicable codes aresuggested. The health care provider will have the opportunity to insertthe correct code or revise the text entry to more closely match thevocabulary used by the code descriptors.

Continuing with FIG. 10, the system and device may be connected to alocal network 1030. This network may be confined to a specific medicaloffice or to a local network of a single hospital. It may be networkedto multiple branches of the hospital. The entered text and code, beingan entry to a patient's Electronic Health Record (EHR), can betransmitted to central server 1040 containing a non-volatile ornon-transitory storage component 1044 and processor 1042 for retention.The storage component 1044 may comprise the data collection 1020 of FIG.10 above. In another embodiment, the updated EHR can be retained by ashared but dispersed/distributed network wherein identical copies of theEHR (as may be updated) are retained. The multiple copies of the ESR canbe compared to ensure not single copies is inappropriately modified.

The storage of the EHR entry in the storage component 1044 of the server1040 frees the memory of the device 1020 to continue processing furtherentries and suggest additional codes correlated to each text entry.

The application discloses an embodiment of the system for providing adocument classification platform within a server. FIG. 10 illustrates asimplified classification scheme. The EHR records 1020 containing thehealth care provider's entries may be communicated in real time to theclassification module of the server 1040 illustrated in FIG. 11discussed above. The text of each entry is reviewed and evaluated in theclassification system 900 and the entries are correlated intopre-existing classification classes 930 (categories) and subclasses 940(subcategories). Initially the classification system is the codeprotocol and the classes and subclasses are as defined in the codedescriptors. It will be appreciated that the code descriptors aremodified as the system learns the alternate terms used synonymously bysome health care providers as contained in multiple EHR entries. Themultiple text terms of the multiple health care providers becomeassociated and are correlated with specific codes as code identifiers.

DEVICES

The classification scheme 900 of FIG. 9 may be implemented inconjunction with the system illustrated in FIG. 10. As shown therein(FIG. 10), a plurality of client devices 1020 may in communication withone or more servers 1040 over a network 1030. The network may be anytype of network such as one that includes the Internet, a local areanetwork, a distributed network, a wide area network, an intranet, etc.Users 1010 are health care providers or support personnel that mayaccess a code protocol for the purpose of conducting, overseeing orperforming the desired code protocol classification with thediagnosis/treatment/test description. Users 1010 may utilize devices1020 to communicate with the server 1040. The user devices 1020, as wellas server 1040, may be configured to communicate via wired or wirelesslinks, or a combination of the two. It will be appreciated that thestorage devices 1026 of each of the three user devices 1020 may containidentical copies of each EHR, thereby creating a distributed network. Inanother embodiment, the server 1040 may be connected to a network ofservers, each containing identical copies of multiple EHRs in adistributed network.

In one embodiment shown in FIG. 10, user devices 1020 may represent adesktop computer, laptop computer, cell or smart phone, tablet device,or other type of computing device operating in conjunction with a server1040. The server may be part of a network as elsewhere described. Theserver communicates with multiple user devices and communicates all codeprotocol modifications created from the machine learning function toeach device. Each of the user devices 1020 may be equipped with one ormore computer storage devices 1026 (e.g., RAM, ROM, PROM, and/or SRAM)and one or more processing components 1024 (e.g., a central processingunit, CPU or microprocessor) that are capable of executing computerprogram instructions. These instructions may include the machinelearning functions.

Continuing with FIG. 10, the device processor may, in one embodiment,perform the classification/sub-classification functions. It will beappreciated that any modification of the code descriptor will becommunicated to the central server 1040 wherein the modification may betransmitted to all client devices 1020. Computer storage device 1026 ofthe server is preferably a physical, non-transitory medium.

Continuing with FIG. 10, any of the user devices 1020 may furtherinclude a display 1022 that is capable of rendering an interface such asthe ones described in subsequent sections and one or more input devices1028 (e.g., keyboard, microphone, camera, video camera, scanner,joystick, remote control device, and/or touchscreen). Users 1010 maymanipulate interfaces rendered on the display 1022 using the inputdevices 1028 to communicate with the server 1040.

In some embodiments, server 1040 comprises one or more mainframecomputing devices that execute a web server for communicating withclient devices 1020 over the Internet. The storage medium on server 1040can store applications or software code that is configured to assistusers 1010, e.g., health care providers, in creating entries pertainingto diagnosis/treatment/tests.

Specifically, server 1040 may be configured to provide documentclassification services (illustrated in FIG. 10) utilizing one or morecode protocols to users 1010 via an interface displayed on user devices1020. It will be appreciated that the user devices may display enteredtext, suggested codes and code descriptors as shown in FIG. 12a .Returning to FIG. 10, server 1040 may be configured to perform the stepsin any of processes of FIGS. 12a-12c, 13a-13g and may further beconfigured to transmit data for displaying the interfaces shown in FIGS.12a, 12b, and 12c and 10. For example, server 1040 may cooperate, e.g.,assist in code correlation, with a user device 1020 to present suggestedcode entries and code classifiers from the processing unit 1042 of theserver to a user 1010, and to display a user interface that permits theuser to enter codes relevant to an EHR entry.

Further, the storage devices 1026 or 1044 (FIG. 10) may be internal orexternal physical media on which an EHR document 920 of FIG. 9, or aportion thereof may be stored, imported or accessed. Storage devicesshown in FIG. 10, 1026 or 1044 may be located on yet another storagemedium or facility, such as a data storage warehouse, server farm, cloudstorage facility, or file hosting service.

One useful feature provided by this system relates to the fact that anumber of classification processes may continue to run on server 1040(FIGS. 10 & 11) while awaiting a user coding decision (described furtherbelow) for the suggested codes and code classifiers. This usefulfeature, which permits continued document classification at the multipleuser devices while awaiting a user response, is facilitated by a uniqueclassification forking scheme that prioritizes the processing ofdocuments, thus allowing real-time interaction between classificationsystem 900 of FIG. 9A and FIG. 9B and user 1010 of FIG. 10. Anotheruseful function performed by server 1040 relates to the server's abilityto update the code modifiers in real time so that all users (includingusers via a network) are benefiting from the increased accuracy betweenthe vocabulary of the health care providers and the codes of the codeprotocol.

It should be noted that the system in FIGS. 10 & 11 are merely meant todemonstrate one embodiment of an operating environment and should not beconstrued as limiting in any manner whatsoever. The particularconfiguration in FIG. 10 can be altered in numerous ways withoutdeparting from the principles of this disclosure. For example, it shouldbe noted that the functionality of server 1040 in FIG. 10 may be carriedout by a plurality of servers. Likewise, although the FIG. 10 depicts asingle server 1040 connected to three client devices 1020, any number ofservers 1040 and client devices 1020 may be utilized with classificationsystem 900 of FIG. 9A

, and classification system 900 may be configured in a variety ofdifferent ways (e.g., in a distributed computing environment,cloud-based environment, box chain environment, distributed networkand/or client-server environment).

Furthermore, while FIG. 10 illustrates a plurality of client devices1020 in communication with a server 1040 over a network 1030, it shouldbe recognized that the functionality provided by server 1040 to clientdevices 1020 may be performed locally on each of client devices 1020.For example, client devices 1020 may utilize an application and/orserver that executes locally on client devices 1020 to perform thefunctions of server 1040. Thus, any functionality of server 1040 whichis described herein can alternatively be implemented by a client device1020, and vice versa.

The system suitable for storing and/or executing program code mayinclude at least one processor coupled directly or indirectly to memoryelements through a system bus. The memory elements can include localmemory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code to reduce the number of times code is retrieved frombulk storage during execution. Input/output or I/O devices (includingbut not limited to keyboards, displays, pointing devices, touchscreens,etc.) may be coupled to the system either directly or throughintervening I/O controllers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, WiFi, cable modem and Ethernet cards are just a few ofthe currently available types of network adapters.

Embodiments described herein may be hardware-based, software-based ormay comprise a mixture of both hardware and software elements. Thus,while the description herein may describe certain embodiments, featuresor components as being implemented in software or hardware, it should berecognized that any embodiment, feature or component that is describedin the figures or description herein may be implemented in hardwareand/or software. In certain embodiments, particular aspects areimplemented in software, which includes but is not limited to firmware,resident software, microcode, etc.

Initialization Interface

Initialization interface 101 of FIGS. 18 & 19 allows the health careprovider (user) 1010 of FIG. 10 to initialize classification system 900(FIG. 9). Initialization interface 101 may allow user 1010 to create orspecify classes 930 and subclasses 940 for a classification problem.User creation or specification of classes 930 and subclasses 940 (FIG.9) may include the ability to annotate or attach a description of eachclass 930 or subclass 940. For example, user 1010 (FIG. 10) may describea class 930 or subclass 940 as being related to a patient medical issuesuch as a “knee sprain” or may describe class 930 or subclass 940 asbeing “radiographic examination of a knee” or “X-ray image of leftknee”. (As the above examples should make clear, the code protocol andcode modifiers may pertain to testing.) In some embodiments, the healthcare provider 1010 need not specify classes 930 or subclasses 940 for aclassification problem. It will be appreciated that the classificationmay be performed by the classification system 900. As discussed, theclassification system may comprise a CPU or similar programed with theappropriate code protocols and capable of machine learning. Creation orspecification of classes 930 or subclasses 940, will, in one embodiment,begin with the up loading of a code protocol. As illustrated above, thecode protocol will have code descriptors. The descriptors will providesubject identity for each code. Also, in some embodiments, thealphanumeric organization of the code protocol identifies the class andsubclasses. (As already mentioned, the learning function of the systemwill allow further descriptive value to be added to or modification ofthe code descriptors.) The classification system 900 may initialize orcreate data constructs associated with the system (e.g., priority queuesand/or classifiers). The classification function shown in FIG. 9 may beperformed by the processor 1024 or 1042 of FIGS. 10.

Returning to FIG. 18, initialization interface 101 also allows thehealth care provider 1010 of FIG. 10 to define or categorize portions ofthe EHR document 920 of FIG. 9. For example, initialization interface101 may display an interactive display window (see FIG. 12a ) on theuser device 1020 suitable for creating classifications or subclasses,e.g., diagnosis, description of specification of treatment to beperformed, treatment results, tests order, test results, etc. It will beappreciated that the user device 1020 of FIG. 11 may contain a display1022 and input interface 1028. The initialization interface may allowthe health care provider to selecting past patient information, e.g.,selected index portions of the patient's EHR files or directories, fromlocal or network storage. (See FIG. 10, File storage 1020.) This stepmay be initialized by the health care provider utilizing the datainputted onto the display, i.e., the health care providers (draft)diagnosis, etc. Files (excepts from past patient EHR entries) selectedby a user 1010 may be contained in the document collection 1020. (Ofcourse, the EHR is property of the patient and the patient may directlyprovide access to the requested EHR records. The health care providersbeing authorized custodians of a copy of the patient's EHR, i.e., theEHR document 920.)

In a preferred embodiment, the entries of the health care provider,descriptions of procedures or treatment, test results, etc., are addedto the patient's EHR 1020.

Note also that EHR records may be added to the system collection bycoupling a device or cable with server 1040 or client device 1020. Forexample, after inserting one or more external storage devices (such as aUSB, SATA, or Thunderbolt drive), network attached storage (NAS), orsimilar device into a corresponding port on client device 1020 or server1040, the files or documents contained thereon are added to documentcollection 1020. Although the documents with the collection 1020illustrated in FIG. 10 are often refenced as a single patient's EHR, thecollection 1020 may, in other embodiments, contain the EHR records ofmultiple patients. The health care provider will identify the correctEHR by patient identifiers e.g., name, DOB, social security number, etc.Again, see FIG. 12a as one embodiment of this identification step.

Initialization interface 1022 may also allow the health care provider1010 to indicate settings for active learning module 1160. See FIG. 11.It will be appreciated that active learning is the machine learningdiscussed above. For example, initialization interface 1022 allows user1010 to determine whether or not classification system 1000 100 will useactive learning. Initialization interface 1022 may also allow user 1010to specify other users or experts 1010 for receiving documents ornotifications during active learning and/or review of the initialdocument sets.

In an embodiment, the health care provider 1010 may create a text entryof a patient diagnosis. The text entry may be entered into the clientdevice 1020. In one embodiment, the text will appear in pane 502 a ofFIG. 12a . The text will appear as the health care provider enters thetext via the Input Device 1028 of FIG. 10. The text entry may specify orname the diagnosis, e.g., “appendicitis”. The health care provider maycreate a separate entry describing the treatment to be performed or adescription of a treatment result. The entry pertaining to treatmentresults may be part of a subsequent consultation or in entriesjustifying a patient hospital discharge order. The entry may appear in aseparate pane 502 b.

The text entry may be reviewed by the processor 1024 of the clientdevice 1020. The processor may contain the code protocol as well as therules or program for correlating the text entry to one or more codes,utilizing the code descriptors (contained in the code protocol). In thisfunction, the server is acting as the classification system.

In one embodiment, the user may determine and/or select a class 930and/or subclass 940 to be associated with the text entry (or portion ofthe text entry). As mentioned above, a classification problem(correlation of the health care provider's text entry to one or morecodes) may require machine evaluation of any number of classes 930 andsubclasses 940. The entry may pertain to a pastdiagnosis/treatment/test. Such past event may already be subject to oneor more of code classifications contained in the patient's EHR 920.These past code entries may have utilized modified or enhanced codedescriptors (code modified class description). The processor mayevaluate these past indexed entries in suggesting one or more codeentries to the health care provider via the client device display 1022.In one embodiment, the suggested code classifications may be displayedwith the coded descriptor or modified class description, i.e., classidentifier.

The possibly relevant portions of the EHR pertaining to pastdiagnosis/treatment/test may be temporarily stored in the storage device1026 of the client device. This storage may comprise transitory orvolatile memory.

It will be appreciated that all or a portion of the informationaldocuments pertaining to past patient diagnoses, etc. contained in theEHR may be a member or a non-member of any number of classes 930 orsubclasses 940 of a classification problem (e.g., the documents may berelevant or non-relevant to any number of classes 930 and/or subclasses940 of a classification problem). Stated differently, a portion of theEHR may have no relevance to the classification problem of the currenthealth care provider. Thus, the health care provider 1010 may submitmultiple user coding decisions indicating whether the informationaldocuments in the initial EHR are to be associated with any particularclass 930 or subclass 940 arising from the current diagnosis, etc.

Based upon the coding suggestions (containing the code descriptors ormodified class identifiers) provided to the health care provider basedupon the processor evaluation of the health care provider's text entry,the health care provider may be prompted to revise or edit the entry toenhance its descriptive value. The health care provider may be promptedto provide greater specificity in his/her entry. This may reduce thenumber of displayed codes. It will be appreciated that at this initialstage, the processor may be associating the contents of the originalentry with the code descriptors. This may be viewed as similar to akeyword search. However, the system may select suggested codes utilizingknowledge of past selected code entries, including codes containing auser modified class descriptors (class identifier) for the suggestedcode. This would be machine learning.

FIG. 11 illustrates a further embodiment of the server 1040 of FIG. 10.The initial document set generator 1120 may execute a keyword searchoperation on the past EHR entries contained in the document collection920. The search may use the Wumpus Search Engine (developed at theUniversity of Waterloo) running the BM25 (OKAPI) algorithm or other typeof search engine. For example, the EHR document 920 may be provided tothe search engine for analysis (e.g., the documents may be uploaded orotherwise made available), and a health care provider (user) 1010 may bepermitted to search the document collection providing keyword queries tothe search engine. The search engine may return a subset of the EHRdocument according to the specified search algorithm which satisfy thequery provided by the health care provider. The returned searchdocuments or subsets may be displayed upon the display screen 1022 ofuser's device 1020. Each of the entries of the EHR in the subset (or aportion thereof) may be ranked based on how closely the EHR documentportion or utilized code matches the user's query. The subset ofdocuments (or portion thereof) returned in response to the user's querymay be displayed to the health care provider as relevant patienthistory. For example, only those EHR entries above a certain rank may beadded to the display. In another embodiment, the code and modified codedescriptor may be displayed as a suggested code entry. Naturally, theform of user query (and the results) may be dependent on theclassification problem to be solved.

Code Protocol Amendment

In one embodiment, the system may derive and create amendments to thecode descriptors based on health care provider's coding decisions. In afurther embodiment, these proposed modifications to the original codedescriptors of the code protocols may be collected in the system memoryfor evaluation. If identical or similar modifications are frequentlysuggested and collected by the system, the code descriptor utilized bythe system may be amended. The step of collecting proposed codedescriptor changes for evaluation and comparison may allow the codedescriptors, as thus code usage, to more closely align with the intentand meaning of the health care providers. The step of collecting groupsof proposed changes may prevent the code from being modified based uponunsupported or unjustified code selections of one or few health careproviders.

Referring to FIG. 11, in some embodiments, the document informationprofiles derived from the user coding decisions may include a vector orarray derived using a 4-gram technique. The description of the documentinformation profile generator 1130 and/or a classifier generator 1140provides with regard to how the user coding decisions 555 of FIG. 12cmay be utilized in creating document information profiles and codeidentifiers.

Generally speaking, the health care provider's entry (text description)into the display 1022 of user device 1020 (FIG. 10), as shown in thewindows (panes) 502 a & 502 b, etc., of FIG. 12a , may be utilized bythe classification system to determine whether or not a code should besuggested or whether a code entered by the health care provider shouldbe accepted by the system without modification of the health careprovider's entry. These concepts are discussed in further detail below.

Further, in one embodiment, the system's initial document set generator1120 may communicate and coordinate with document manager 1110 to accessand display indexed portions of the patient's existing EHR 920 (FIG. 9).In one embodiment, the health care provider may control activation ofthis feature. In an embodiment, for example, the health care provider'sentry of a diagnosis, etc., may prompt the suggestion of possiblyrelevant codes. Simultaneously, the EHR may be reviewed by the processorfor similar codes or similar text. These portions of the EHR may bedisplayed 1022 of FIG. 10 to the health care provider using the clientdevice 1020. In this example, the contents of the displayed documentsmay be utilized by the health care provider in creating a diagnosis ortreatment plan.

In certain embodiments, e.g., when merging active learning into a singlephase, generation and review of initial code descriptors is notperformed and instead classification system 900 of FIG. 9 may use aniterative active learning approach.

FIG. 12a illustrates an embodiment of the disclosure comprising asuggested format for the display screen 1022 of the client device 1020(see FIG. 10). The health care provider may enter examination notes 502a utilizing the device input interface 1028. In one embodiment, theleft-hand screen 501 a begins to become populated with suggested orprompted code entries based upon the text of the health care providerentered in 502 a. The suggested code entries include both the code andthe code descriptor. The disclosure utilizes machine learning to selectpossibly applicable codes from the code protocol. The device utilizeslearned past selected or entered codes made by a health care providerwherein the health care provider's text description was similar to thecurrent entry. Relevant portions of past EHR entries may be displayedfor the health care provider's consideration. This display of relevantportions of a past EHR entry may appear in window 502 a or 502 b or, inanother embodiment, in a separate window. The display of the past EHRentries may be a function of the search option shown in FIG. 12 a.

Patient Identity and Data Authenticity

Also disclosed in the embodiment illustrated in FIG. 12a is therequirement that the patient be identified 510 by name, DOB, and othercriteria such as social security number, assigned number from theentity. The entity may be the health care provider's doctor's office,the emergency room of a hospital, an outpatient clinic or similar. Inone embodiment, each entity may be part of a patient informationnetwork. Each entity may have a network identifier or number. Theparticipants in the network may share patient information if authorizedby the individual patient.

To facilitate efficiency of the health care provider's time and effort,the health care provider may input his/her observations, etc., 502 aelectronically. In one embodiment, the information may be entered on aformat similar to that shown if FIG. 12a . First the patient isidentified by name, DOB and/or other identifying information S10. Toensure the authenticity and validity of the health care provider'sobservations, diagnosis, etc. recorded in window 12 a, the health careprovider may first be required to “sign in” 520 to the network (it beingappreciated that the network may be a single health care provider'soffice or expanded network as suggested above). The health care providermust enter a user name and password. If the network recognizes the username and the correct association of the name with the password, thehealth care provider's note, diagnosis, etc. may be entered onto theillustrated form. The network will communicate the suggested codes andcode descriptors that will appear in window 501 a of FIG. 12 a.

The integrity of the data, i.e., the validity of patient data and thedata accuracy, can also be ensured in other embodiments utilizing blockchain and distributed network techniques. These applications may alsouse private and public key technology as described below in relation toFIG. 13 e.

Further, the health care provider may request 530 that the otherentities of the network also provide relevant information that theypossess pertaining to the identified patient. The information may becontained within the patient's EHR or known to one or more of thenetworked entities. This request may be easily made by the health careprovider by indicating such a request in the space provided within theform utilized for entry of the health care provider's notes pertainingto the patient. The health care provider may request information fromone or more identified entities or from all the participating entitiesof the network. In one embodiment, the search request will automaticallybe submitted utilizing the search function initiated by activating thesearch tab “Submit” 551. While awaiting the result of a requestedsearch, the health care provider may continue accessing the EHR dataentry screen. The network may be comprised of entities similar to thenetwork of the Health Information Exchange for South East Texas,http://www.ghhconnect.org.

As described elsewhere, the search may be conducted utilizing thesuggested or selected health care codes. These codes appear in thewindow 501 a adjacent to the window 502 a containing the health careprovider's text notes. In a further embodiment, the health care providermay be able to modify the search request, using information supplied forthe past EHR entries furnished in response to the first request

Note that FIG. 12a discloses an embodiment wherein it is possible forthe user to continue writing notes wherein the complete text extendsbeyond the size of the window 502 a. The continued text can be viewed byseveral methods. As illustrated in FIG. 14a 5a , each window, e.g., 501a, 501 b, 502 a, 502 b, may contain a scrolling device 505 that can varythe contents of the window. The complete text can be viewed in thewindow by other methods such a holding a mouse key and moving the cursorup or down within the window. In another embodiment, the contents of awindow may be varied by a configuration utilizing the vertical scrollingor movement of a user's finger across the surface of the window ordisplay screen 1022 of the user device 1020 discussed in FIG. 10.

It will be appreciated that the device 1020 may display 1022 images suchas images of hand written entries contained in a past EHR entry createdby health care provider or other authorized individual. X-ray or MRI orCT images may also be displayed. The device may also contain a featureallowing a single pane to be expanded to occupy the entire displayscreen, thereby facilitating accurate understanding of the image.

FIGS. 12b & 12 c illustrate another embodiment of an interface 550 whichallows the health care provider 1010 to navigate between the health careprovider's EHR entry and the coding protocol with the purposes ofallowing the health care provider 1010 to make prompt coding decisions551 and capture those coding decisions with the relevant EHR entry.

In this screen display 590, the past relevant EHR entry is displayed.The EHR entry is selected by the processor based upon the selected codeentries or text entries of the current health care provider. In theembodiment shown, the health care provider may scroll through the pastEHR entry utilizing arrow keys 570 or the arrow keys contained withinthe control panel 540. It will be appreciated that the text entries maybe used in the search. This will allow productive access to the past EHRentries that have not been previously annotated or indexed utilizing thecode protocols.

Data Entry Validation

As indicated above, only an authorized user, i.e., health care providersuch as a physician, nurse, physician's assist, nurse practitioner,etc., may enter data that may be included as part of a patient's EHR. Asfurther indicated above, the identity of the health care provider may berequired to be authenticated 520 prior to the entry of the data. SeeFIG. 12a . Authentication may be achieved by various methods. All suchmethods are included within the scope of this disclosure.

In another embodiment, the document source 920 (FIG. 9) may need to beauthenticated in order that the current health care provider may trustthe authenticity of the received documents.

In the embodiment illustrated in FIG. 12a , the health care provider isrequired to enter an established user name (first authenticationinformation) and corresponding password (second authenticationinformation). See the sign in spaces 520 of FIG. 12 a.

FIG. 13a is a flow diagram illustrating a method allowing the healthcare provider to obtain access to an EHR.

The advantages of this embodiment include that user login, i.e., thehealth care provider, utilizes a two factor protocol comprising twostages: a first stage, including anonymous authentication S100 and asecond stage, including identifying information authentication S200, inwhich the user needs to provide the user name and password forauthentication. It will be appreciated that entering the first stage maynot require the user name and password to be provided and only therandom verification code is acquired to be verified by a directanonymous authentication method to allow the access request to move tothe second stage. The authentication of two stages can effectivelyreduce the risk of the user login information leakage and improvesecurity.

In step S100, the recipient of the access/search request may be a singleentity or a broad network of health care providers. The randomverification code acts as challenge information for anonymousauthentication.

In step S200, the acquired user name and password information isauthenticated when the anonymous authentication (first stage) issuccessful, wherein the user name and password information may bepre-stored by the recipient entity or acquired through user input.

It will be appreciated that there are a variety of ways to implement theanonymous authentication to the random verification code in step S100.FIG. 13b illustrates one example. FIG. 13b above illustrates the methodsteps for performing anonymous authentication of the randomauthentication code, i.e., the first stage of the two stageauthentication.

Beginning with the first step S110, login session identification codeand a random verification code is generated according to a login requestof the health care provider for accessing the information system. Thelogin session identification code is temporary and unique.

In the second step S120 asymmetric cryptographic algorithm (RSA) isperformed, generating a encryption and signature to the login sessionidentification code, the random verification code and an authenticationserver network address with an information system private key and a userpublic key.

It will be appreciated that an authentication server may be utilized toprovide a function of registration of a health care provider, e.g., ahospital participating in a network. This health care provider or EHRcustodian, i.e., recipient, is receiving a request from a current healthcare provider. This current health care provider may be an emergencyroom doctor. This request may be activated after an authenticationapplication is installed by the recipient. The recipient should first beregistered in the authentication server, and the recipient may create alink with the authentication server at any time through linking to theauthentication server network address for authentication. The knowntechniques in the prior art can achieve the RSA encryption andsignature, and the transmission of the authentication information ismore secure and reliable when transmitted with the help of theasymmetric cryptographic technique.

Encryption of Device And EHR Data

It will be further appreciated that asymmetric cryptography, also knownas public key cryptography, uses public and private keys to encrypt anddecrypt data. The keys are simply large numbers that have been pairedtogether but are not identical (asymmetric). One key in the pair can beshared with everyone and is called the public key. The other key in thepair is kept secret; it is called the private key. Either of the keyscan be used to encrypt a message; the opposite key from the one used toencrypt the message is used for decryption. It will be appreciated thatencryption is the method by which plain text or any other type of datais converted from a readable form to an encoded version that can only bedecoded by another entity if they have access to a decryption key. Itwill be further appreciated a key is a piece of information (aparameter) that determines the functional output of a cryptographicalgorithm. For encryption algorithms, a key specifies the transformationof plaintext into ciphertext, and vice versa for decryption algorithms.Keys also specify transformations in other cryptographic algorithms,such as digital signature schemes and message authentication codes.

Stated further, asymmetric cryptography is any cryptographic system thatuses pairs of keys: public keys which may be disseminated widely privatewhich are known only to the client. This accomplishes two functions:authentication, where the public key verifies that a holder of thepaired private key sent the message, and encryption, where only thepaired private key holder can decrypt the message encrypted with thepublic key.

In a public key encryption system, any person can encrypt a messageusing the receiver's public key. That encrypted message can only bedecrypted with the receiver's private key. To be practical, thegeneration of a public and private key-pair must be computationallyeconomical. The strength of a public key cryptography system relies onthe computational effort (work factor in cryptography) that would berequired to find the private key from its paired public key. Effectivesecurity only requires keeping the private key private; the public keycan be openly distributed without compromising security.

Asymmetric cryptography systems often rely on cryptographic algorithmsbased on mathematical problems that currently admit no efficientsolution, particularly those inherent in certain integer factorization,discrete logarithm, and elliptic curve relationships. Public keyalgorithms, unlike symmetric key algorithms, do not require a securechannel for the initial exchange of one or more secret keys between theparties.

Because of the computational complexity of asymmetric encryption, it isusually used only for small blocks of data, typically the transfer of asymmetric encryption key (e.g. a session key). This symmetric key isthen used to encrypt the rest of the potentially long message sequence.The symmetric encryption/decryption is based on simpler algorithms andis much faster.

In a public key signature system, a person can combine a message with aprivate key to create a short digital signature on the message. Anyonewith the corresponding public key can combine a message, a putativedigital signature on it, and the known public key to verify whether thesignature was valid, i.e. made by the owner of the corresponding privatekey. Changing the message, even replacing a single letter, will causeverification to fail. In a secure signature system, it iscomputationally infeasible for anyone who does not know the private keyto deduce it from the public key or any number of signatures, or to finda valid signature on any message for which a signature has not hithertobeen seen. Thus the authenticity of a message can be demonstrated by thesignature, provided the owner of the private key keeps the private keysecret.

The third step S130 of this example embodiment involves converting theencrypted and signed login session identification code, randomverification code and authentication server network address into a QR(Quick Response) code. The known QR code conversion software or programin the prior art can achieve the QR code conversion. It will beappreciated that the transmission of the authentication information ismore secure and reliable with the help of the asymmetric cryptographictechnique.

FIG. 13c is a flow diagram illustrating a process of authenticatinginformation of a user name and a password according to one embodiment ofthe present disclosure.

In another embodiment, a request to login to the system includes firstsuccessfully performing anonymous authentication to a randomverification code and second, authenticating the user name and password.

Another embodiment of the disclosure described above includes a devicefor providing access to the EHR system including a verification codeauthentication module and user name and password authentication moduleconnected to the verification code authentication module. Theverification code authentication module is configured to performanonymous authentication to a random verification code generatedaccording to a login request for accessing an information system ofclient; and the user name and password authentication module isconfigured to authenticate acquired user name and password informationwhen the anonymous authentication is successful.

In one embodiment, the user name is converted and a credential thatincludes a public key may be extracted from the user name. The passwordmay be decoded and may be decrypted based on the public key extractedfrom the user name. The user name and password may be authenticated bycomparing the decrypted password to the extracted credential. If thecomparison results in a match, the computing device may beauthenticated.

In some embodiments, the user name comprises supplemental informationconcatenated to the retrieved credential. The supplemental informationmay comprise a time stamp generated at the time the user name isgenerated. The time stamp may be extracted from the user name. After theuser name and password are compared, the time stamp may be verified inorder to complete authentication. The time stamp may be verified bycomparing the extracted time stamp to previously received time stampsfor that computing device. If the extracted time stamp is different fromthe previously received time stamps for the computing device, theextracted time stamp may be confirmed.

An example system of authenticating a computing device is describedfurther below with reference to FIG. 13e . In some embodiments, thesystem may comprise computing device 220 (e.g., user device from FIG.10), previously established credential 692 (e.g., digital certificate,PKI, etc.), trusted authority 693 (e.g., certificate authority), publickey 694, private key 695, authentication computing device 696, directory697, database 698, and computing device 699 (e.g., servers). In someembodiments, the device seeking authentication may be any suitablecomputing device (e.g., client computing device, peer computing device,etc.) that seeks authentication in an authentication system.

In some embodiments, authentication computing device 696 and computingdevice 220 (1020 of FIG. 10) implement a username and passwordauthentication policy. In this embodiment, first authenticationinformation may comprise a user name and second authenticationinformation may comprise a password. Computing device 220 may provideone or more credentials via the user name and password to authenticationcomputing device 696 and the one or more credentials may beauthenticated by authentication computing device 696. In an example,computing device 220 and authentication computing device 696 areassociated with an Electronic Health Record system. In another example,the authentication computing device 696 has no prior knowledge ofcomputing device 220.

In some embodiments, computing device 220 (FIG. 13e ) and authenticatingcomputing device 696 implement a public key cryptography system. Forexample, public key 694 and private key 695 may comprise a set ofasymmetric keys. When data is encrypted using private key 695, publickey 694 may be used to decrypt the data. For example, a digitalsignature for computing device 220 may comprise hashing data prior totransmission, e.g., based on a 256-bit secure hash algorithm (SHA), andthen encrypting the digest of the hash with private key 695. The digitalsignature may be decrypted using public key 694. Any other suitablehashing algorithm (e.g., SHA-224, any hash algorithm published by theNational Institute of Standards and Technology, etc.) may be used.

A hash algorithm is a function that converts a data string into anumeric string output of fixed length. The output string is generallymuch smaller than the original data. A hash function is any functionthat can be used to map data of arbitrary size to data of a fixed size.The values returned by a hash function are called hash values, hashcodes, digests, or simply hashes. Hash functions are often used incombination with a hash table, a common data structure used in computersoftware for rapid data lookup. Hash functions accelerate table ordatabase lookup by detecting duplicated records in a large file. Theyare useful in cryptography. A cryptographic hash function allows one toeasily verify that some input data maps to a given hash value, but ifthe input data is unknown, it is deliberately difficult to reconstructit (or any equivalent alternatives) by knowing the stored hash value.This is used for assuring integrity of transmitted data, and is thebuilding block for HMACs, which provide message authentication.

A cryptographic hash function is a special class of hash function thathas certain properties which make it suitable for use in cryptography.It is a mathematical algorithm that maps data of arbitrary size to a bitstring of a fixed size (a hash) and is designed to be a one-wayfunction, that is, a function which is infeasible to invert. The onlyway to recreate the input data from an ideal cryptographic hashfunction's output is to attempt a brute-force search of possible inputsto see if they produce a match or use a rainbow table of matched hashes.The input data is often called the message, and the output (the hashvalue or hash) is often called the message digest or digest.

The ideal cryptographic hash function has five main properties:

-   -   i. it is deterministic so the same message always results in the        same hash;    -   ii. it is quick to compute the hash value for any given message;    -   iii. it is infeasible to generate a message from its hash value        except by trying all possible messages;    -   iv. a small change to a message should change the hash value so        extensively that the new hash value appears uncorrelated with        the old hash value;    -   v. it is infeasible to find two different messages with the same        hash value.

Authenication

FIG. 15a provides an illustration of the steps of an embodiment whereinthe health care provider initiates a search 802 of past EHR entries thatmay pertain to the same medical issue now being confronted by thecurrent health care provider. The health care provider may firstdesignate the entities 803, 804, 805 to receive the search request. Seealso the categories 530 illustrated in FIG. 12a , i.e., Search locationsand Search scope. Note the health care provider may create a customsearch which allows specified codes or text to be searched. The searchwill be initiated by the health care provider selecting the “Search”button. 531.

FIG. 15a further illustrates an embodiment for authenticating the partyrequesting the search 806 by inserting a first factor identification.Note in the example provided, the requestor, i.e., user or clinician,may make 3 attempts to supply a correct authicator (password oridentifying credential) 808, 809. If the requestor's authentication isaccepted, the requestor may be subjected to a second layerauthentication 810. This may comprise two factor authentication andrequire a second level of acceptance 811. This may be an authenticationcode separately texted or emailed to the requestor. Again, therequesting party may have 3 attempts to submit an acceptable secondfactor identifier 812, 813. Upon acceptance of the requestor'scredentials, the search may be performed. The search results may beencrypted and returned to the requesting party (health care provider)814.

As illustrated FIG. 15a illustrates the user authentication steps806-814. Also see FIG. 12a 520 requiring entry of a user ID andpassword. The authentication factors may be entry of the user name andpassword. The system may, in another embodiment, employ a two factorauthentication process 810. Note that the receiving/disclosing entity(“Recipient Network”) may encrypt the patient information transmitted tothe health care provider 814.

FIG. 15b expands the steps of one embodiment wherein the Recipient

Network discloses responsive or relevant EHR entries to the requestinghealth care provider. First, the requesting health care provider may beauthenticated 8141. The patient is next identified 8142 and adetermination made whether the recipient network possesses an EHR forthe patient. In the illustrated embodiment, the health care provider mayprovide a declaration that the requested information is required forcontinued health treatment of the patient 8143. This document maysatisfy the Recipient Network that a patient consent is not required. Itwill be appreciated that this step will comply with the Health InsurancePortability and Accountability Act (HIPAA). If the Recipient Network isthe custodian of any patient EHR documents containing informationresponsive to the search request (whether by text entry or codes listedin the search request) the responsive information can be provided to thehealth care provider 8145, 8146, and 8147. If the Recipient Networkrequires patient consent to the release of information, theauthenticated health care provider is to be notified 8148.

FIGS. 16a through 16e illustrate an authentication process that mayutilize a QR code 901

FIG. 16a illustrates a log in interface 900 containing an authenticationcode 901, along with webpage (e.g., “www.singou.mo”) 902 correspondingto a unique URL and a bookmark column 903 that includes a bookmarklet904 (shown as “[+]SINGOU”). The authentication code 901 comprises a QRcode that is generated in response to retrieval of a session ID from agateway server. The authentication code 901 includes information such asa session ID and the URL that are to be obtained by a mobile device whenreading (e.g. scanning) the authentication code 901.

FIG. 16b illustrates a user interface 920 at a mobile device inaccordance with an example embodiment. The user interface includes ablock 921 for inputting a user name, a block 922 for inputting apassword, and one or more triggers or buttons 923, 924, and 925.

As an example, when no user name and password associated with a URL thatis extracted from an authentication code displayed by a client device isfound in a list of URLs, user names and password in the mobile device, auser inputs a user name and a password into blocks 921 and 922respectively.

The one or more buttons perform a variety of functions. For example, inresponse to activation of the button 923, the mobile device stores aURL, a user name and a password associated with the URL into the list inthe mobile device. In response to activation of the button 924, themobile device denies login to a computer system. In response toactivation of the button 925, the mobile device generates a countervalue associated with a URL for voting the URL.

FIG. 16c illustrates a process for processing a user name in accordancewith some embodiments. The process begins at step 941, where thereceived user name is converted into PEM format or any other suitableformat. In some embodiments, the user name will be received in thedesired format (e.g. PEM), and the converting will be unnecessary. Theprocess of FIG. 16c may move from step 941 to step 942, where acredential (e.g., digital certificate) is extracted from the user name.In an example, the user name may have been received as a concatenationof supplemental information and a digital certificate, and theextraction may comprise separating the digital certificate from thesupplemental information. The extraction may comprise additional steps,such as converting a format for the user name, decoding the user name,separating the credential from other appended data, etc.

From step 942 the process of FIG. 16c may move to step 943, wheresupplemental information is extracted from the user name. In an example,the user name may have been received as a concatenation of supplementalinformation and a digital certificate, and the extraction may compriseseparating the digital certificate from the supplemental information.The extraction may comprise additional steps, such as converting aformat for the user name, decoding the user name, separating thesupplemental information from other appended data, etc.

The process of FIG. 16d illustrates an embodiment of converting areceived password. In an example, the received password may have beendigitally signed 944 by a computing device, and the conversion mayinclude decrypting 946 the digitally signed password.

FIG. 16e shows the application server 991 as an information system andthe login application has a function of QR code scanning and a propertyof network connection.

The user from a user device 982 links to the application server 991 overthe network, and sends a login request, and the application serverreturns a user login interface 981. The application server generates alogin session identification code and a random verification code for thelogin request. The application server performs RSA encryption andsignature to the login session identification code, the randomverification code and authentication server network address with theserver private key and the user public key, to generate an encryptedciphertext.

The application server converts the encrypted ciphertext 986 into a QRcode 983 and display the QR code on the user login interface at theclient; the login application installed in the user scans the QR codethrough a camera device and decodes the QR code 980.

The login application decrypts the decoded QR code with the serverprivate key and the user public key 999 to obtain the login sessionidentification code, the random verification code and authenticationserver network address 998. The login application links theauthentication server to perform anonymous authentication to the randomverification code, and the authentication server returns a responsemessage;

The application server determines whether the anonymous authenticationis successful according to the response message, and if the anonymousauthentication is successful 998, the application server informs theauthentication server to start the second stage of authentication 997.The login application 981 then queries the user name and the passwordinformation stored in the user, and the user name and the passwordinformation can be also acquired by user input.

The login application performs encryption and signature to the loginsession identification code, the user name and the password informationwith the information system private key and the user public key togenerate a new encrypted ciphertext 986.

The login application links the authentication server network address totransfer the new encrypted ciphertext to the authentication server. Theauthentication server then transfers the new encrypted ciphertext to theapplication server over the network.

The application server performs signature authentication and decryptionto the new encrypted ciphertext with its own server private key 996 andthe user public key 985 to obtain the login session identification code,the user name and password information; and the application serverauthenticates the user name and the password information, returns asuccessful login message when the authentication is successful and thelogin procedure is completed that the user's login is successful, andreturns an error message when the authentication is unsuccessful.

Compared with the prior art, the above method and device for informationsystem access authentication has the following advantages.

1. The user's login of the information system includes two stages: afirst stage, including anonymous authentication, in which it is notrequired to provide the user name and password, and it is only requiredto acquire the random verification code and verify the randomverification code with a direct anonymous authentication method; and asecond stage, including identifying information authentication, in whichthe user need to provide the user name and password for authentication.The authentication of two stages can effectively reduce the risk of theuser login information leakage and improve security.

2. Two-factor authentication (i.e., QR code authentication and user nameand password authentication) is required when a user logs in theinformation system, which combines the QR code technology and theasymmetric encryption technology to make the transmission of theauthentication information more secure and reliable.

3. With the application software which facilitates the scanning of theQR code and the input of the password, the security is improved whilethe user's operation experience is also improved.

In the embodiment of the interface display 550 illustrated in FIG. 12b ,the health care provider's EHR entry appears in the display window 590.This may be the client device 220 (1020 of FIG. 10). In an embodiment ofFIG. 12b , portions of the existing EHR may also be displayed. Thedisplay window 590 may include a scroll bar 570 to facilitate review ofthe current document should it be too large for display window.

User interface 550 may also include a number of user interface reviewelements for entering user coding decisions. The interface also includesa display for suggested codes and code descriptors 591. In anembodiment, the health care provider may designate one or more codes fordisplay. The health care provider may request codes by word entry, e.g.,“knee strain” utilizing the search box 560. The processor may display alisting of codes and code descriptors relevant to “knee strain”. It willbe appreciated this step may be performed without the word searchfunction that can be utilized in the processor code suggestion step.

Alternatively, the health care provider may enter a code for a classdesignation and the processor will respond with a display of subclasseslistings. The health care provider may then select among the subclasslistings.

Referring to FIG. 10, the health care provider can accept one or more ofthe displayed codes for indexed entry into the EHR (along with thehealth care provider's text diagnosis/treatment/test entry). Thisacceptance can be via the input device 1028 of the client device 1020,e.g., highlighting and pressing the keyboard enter key, using a mouse orsimilar device by clicking on a highlighted entry, etc. It will beappreciated that this step can reduce, and perhaps eliminate, the needfor review by a coding individual. The codes entered by the health careprovider, suggested by the system of this disclosure utilizing machinelearning, may be used for both EHR indexing and billing. The systemfacilitates more prompt payment and prompt searching of past EHR entriesfor productive administration of health care, e.g., eliminatingduplicate tests.

Referring to FIG. 12c , some status elements, that may be used toindicate the coding decisions 555, may be used in conjunction with othercodes (e.g., flag). User interface elements may also include a text oredit box 591 for adding notes to a user coding decision 555 of FIG. 12c, which allows for an elaboration on a decision to flag a document.Similar user interface elements (scroll bar 505 or text display arrows570, etc.) may be presented for each class 130 and/or subclass 140.Alternatively, user 210 may be presented with a user interface reviewelement (e.g., list box 501 a and/or arrows 570) for selecting a class130 and/or subclass 140 of the classification problem and selecting,applying and recording user coding decisions 555 of FIG. 12c . In someembodiments, instead of indicating a class 130 or subclass 140 for auser coding decision 555 by having user 210 select a class 130 orsubclass 140 using a suitable interface element, user interface 550informs the user of the class 130 or subclass 140 being reviewed. Forexample, user interface 510 may indicate the current class 130 orsubclass 140 under review to user 210 using a suitable interface element(e.g., status bar 580).

Referring to FIG. 12b , user interface 550 may also include a number ofinterface elements 540 for navigating the health care provider's EHRentry or displayed codes and code descriptors. A submit button 531 or551 may also be presented for recording or accepting the health careprovider's EHR entry or related coding decision. Use of navigation orother user interface elements may trigger error-checking code orsubroutines to apprise the user of a possible error condition (e.g., nocoding decision made).

Referring to FIGS. 12a and 12b , a user interface for review of an EHRentry 502 a, 502 b, etc. or 590 may also include an undo operation. Anundo operation may be executed by the health care provider 1010 (FIG.10) interfacing with an appropriate interface element for example, undobutton 541. An undo operation may also reverse the effects of theimmediately preceding user coding decision 555. An undo operation mayalso, or alternatively, change the document under review 590 (e.g.,reverting back to a previous EHR entry made by the health careprovider). An undo operation may be used iteratively to undo the effectsof a series of user interface operations.

Additionally, user 1010 may be presented with interface elements (e.g.,a search box 560) for finding, locating and highlighting text stringswithin the current document under review 590. Those documents of aninitial document set that are selected using a keyword-type search mayalso be displayed with those keywords found in document under review 590highlighted in the display window. User 1010 may also be presented withan interface 570 for skipping from one found keyword or text-string toanother.

User interface 550 may also include a status bar 580 indicating, forexample, patient name, DOB, social security number, assigned patienthealth care provider patient number, etc. The health care provider 1010may change the EHR entry under review 590.

FIG. 12c illustrates how user interface 1011 (which corresponds to item550 of FIG. 12b and item 1020 of FIG. 10) may communicate and coordinatewith document manager 1110 (referring to FIG. 11) to access an existingEHR from a document collection 920 (referring to FIG. 9). For example,user interface 550 (FIG. 12b ) may issue commands to document manager910 in order to retrieve a portion of an indexed EHR for a specificpatient using code descriptors and patient identifiers during the healthcare provider is creating a new EHR entry. As illustrated in FIG. 12c ,the health care provider coding decisions 555 for each EHR entry underreview 590 are captured by the classification system and may be appendedto the EHR entry or stored in a separate file or database. Capture ofuser coding decisions 555 may be implemented at document manager 1110(FIG. 11).

Referring to FIG. 10, the image of a selected portions of an existingEHR entry or the health care provider's current entry and any userinterface review elements may be implemented as windows or panes of asingle display, separate displays, or a combination thereof of devicedisplay 1022. Some or all of the user interface elements may bepresented as an overlay on top of the current document to reviewed, suchthat the user interface review elements will remain stationary while theuser scrolls through the document. The health care provider 1010 may begiven the option of selecting a number of different layouts for userinterface display 1022. In one embodiment, the display format may varydepending upon whether the health care provider is entering patientobservations and possible diagnosis or is reviewing prior relevant EHRextracts. See FIGS. 12a and 12b above. For example, entered data may bedisplayed in a different font or color or background that the display ofpast EHR entries.

User interface 550 (FIG. 12b ) may be implemented in any suitableprogramming language (e.g., C, Java) or in a browser (e.g., InternetExplorer, Chrome, Firefox, Safari) using a document markup language(e.g., HTML or XML). User interface 550 may be a natively programmedapplication or served to a user device from a remote location.

Alternatively, user interface 500 (FIG. 12a ) or 550 (FIG. 12b ), may besimple and minimalist. In some embodiments, user interface 550 is aterminal (text) interface. A simple implementation of user interface 550allows classification system 100 (FIG. 9) to dedicate further resourcesto document processing, thus allowing for faster operation of theplatform.

User interface 550 (FIG. 12b ) may also map the operations of graphicalelements to keystrokes on a keyboard. For example, in some embodiments,health care provider 1010 (FIG. 10) indicates acceptance of an EHR entryor code by pressing an identified key on a standard keyboard (e.g., “a”)and indicates rejection by pressing a different key (e.g., “g”). Bymapping the operations of graphical elements to keyboard keys, a user1010 can process documents faster by avoiding time consuming userinteraction with a GUI pointing device (e.g., a mouse). The health careprovider may also utilize the keyboard arrow keys to scroll through thedisplayed document.

Some or all user interface elements may be mapped to a gesturerecognition system, whereby the user may navigate an initial documentset or make user coding decisions 555 (FIG. 12c ) by issuing a swipe orsweep gesture on a touch sensitive surface (e.g., touchscreen ortouchpad) or in view of a camera, instead of using a button or otheruser similar interface element. For example, vertical swipes mayindicate acceptance or rejection while horizontal sweeps may change theentry or code under review 590. Gesture recognition may be performed bythe software of user interface 550 or in a separate software module orlibrary that interoperates with user interface 550. In certainembodiments, voice recognition is performed where a user performsactions by speaking words or phrases. For example, a user may indicateacceptance by speaking a word or phrase and rejection by speaking adifferent word or phrase.

In other embodiments, a user 1010 (FIG. 10) may not need to review anyinitial document sets. For example, a randomly selected subset ofdocuments from document collection 920 (FIG. 9) may be used toapproximate a set of non-relevant documents. This randomly selected setbypasses user determination and coding and is instead coded byclassification system 900 of FIG. 9 to be non-relevant (e.g., belongingto class N) and is thus also non-relevant to all subclasses 940 of theclassification problem. Subsequent review and classification byclassification system 900 or a user 1010 may alter this coding decision.

In certain embodiments, e.g., when merging active learning (discussedbelow) into a single phase, user interface 550 of FIG. 12b need not beprovided and instead classification system 900 of FIG. 9 may rely solelyon an active learning interface for document review during activelearning iterations.

Machine learning systems are able to update code descriptors orclassifiers, and hence the training set, using further human review ofselected documents. Documents, i.e., coded EHR entries, may be selectedfor review based on one or more factors and/or algorithms discussedfurther below. The selected documents are then reviewed. The review mayconsist of comparison of the EHR entry and the assigned code/codedescriptor or code classifiers. Amended code descriptors (codeidentifiers) can be reviewed in relation to the EHR entry and theoriginal code descriptors. This review will improve the relevancy of thecode descriptors with the EHR entries as created by the health careproviders. This in turn will improve the accuracy of the code to billingdecisions. It will be appreciated that the alphanumeric codes are notamended or modified by the system. Only the code descriptors oridentifiers are amended to enhance relevancy to health care provider EHRentries and to facilitate the correct code is assigned to thediagnosis/treatment/test. Correct code assignment thereby furtherimproving the effectiveness of the EHR classification/indexing systemand the effectiveness of the coding protocol for medical expensereimbursement purposes.

A health care provider 1010 may request that coding assignment system900 use an active learning process during classification. The healthcare provider 1010 may instruct the system to use active learning byinterfacing with classification system 900 using a GUI, a web-interfacepresented by the classification system or through a command line or anyother suitable mechanism. In certain embodiments, classification system900 may default to using active learning. The user may be an experiencehealth care code protocol coder and another experienced health careprovider.

FIG. 14 illustrates an embodiment of the disclosure wherein the healthcare provider begins entry of patient observations or preliminarydiagnosis 702. This may be at the initial patient encounter. Theprogramed device may begin inserting suggested codes 703. This text mayappear in the window 502 a of the user display (FIG. 12a ) or in 590(FIG. 12b ). The system may perform a word search from the entered textand compares the text with the code descriptors of the code protocol703. The suggested codes may be displayed in window 501 a of FIG. 12 a.

The user may accept one or more of the suggested codes 704 or may enterone or more different codes or alter the code descriptors 705. Note thealternate codes or modified code descriptors are transmitted to the codeprotocol 703 or 707 as part of the machine learning function. The codes(original code suggestions, modified code descriptors or acceptedoriginal suggested codes) may be accepted by the user 706 and the codesand code descriptors may be integrated into the EHR. Again, the user(clinician) may revise the code descriptor to the code (alphanumericcode identifier) which maybe incorporated into the programed CPU/deviceas part of machine learning.

Machine Learning

Referencing FIG. 17, it will be appreciated that any document selectionmethod may be used at any active learning iteration. For example, activelearning module 1160 (FIG. 11) may select an EHR entry based upon thehealth care provider's text entry or selected code. Alternatively, thehealth care provider 1010 (FIG. 10) may select an EHR from documentcollection 920 (FIG. 9) using a user interface 1012 (FIG. 17) providedby classification system 900. For example, user interface 1012 may listrelevant text of entered by the health care provider. The text maycomprise text extracted from the patient's existing EHR in a window orpane of a window in a user device 1020. The list of EHR entriespresented to the health care provider from the documents may be rankedor ordered. For example, the health care provider 1010 may enterkeywords or rules into a device window or text box. Document collection1020 may be searched with the entered keywords using an algorithm suchas BM25 (OKAPI) or any other suitable algorithm in order to providerelevance rankings. The listing of relevant EHR entries presented touser 1010 may be ranked accordingly. Alternatively, the document listmay be ordered according to scores calculated by classification process900 (e.g., using priority queues). The order of the list presented tothe health care provider 1010 may be updated in real-time.

In another embodiment, the active learning component may select priorselected codes and code descriptors or code identifiers from evaluatedEHR's of multiple patients. It will be appreciated that no informationconcerning individual patients will be disclosed. The machine evaluationwill be for searching for alternate classifications of observedconditions or diagnoses. For example, has an entry of “sprained knee”been classified M25.56 Pain in knee or M25.66 Stiffness of knee, notelsewhere classified.

Referencing FIG. 15b , in certain embodiments, e.g., when merging activelearning into a single phase, document selection step 814 may be used toselect a document that contributes to the overall objectives ofclassification system 900, namely, achieving high recall, high precisionand using minimal human effort. For example, EHR entry selection stepmay select an EHR entry based upon its position in a priority queue. Forinstance, to select the most likely relevant document to a specifiedcode class or subclass, an EHR entry may be selected at step 814 fromthe top of a priority queue. High precision and high recall can berealized by minimizing overtraining and identifying additional types ofrelevant documents. Assuming that EHR entries near the top of a priorityqueue are similar, it may be beneficial to select an EHR document from aposition near the top of a priority queue or elsewhere within the queue,as opposed to purely from the top of the queue, or a random EHR entry toachieve greater sampling diversity.

To determine which document to select from a priority queue, differenttechniques may be utilized. It will be appreciated that it is the EHRentries that are of interest. The EHR document will contain numerousentries. An EHR document is likely too voluminous to be of meaningfulinterest due to time required to parse the entire EHR. The entries areselect by one of the alternate methods discussed above.

For example, the process may skip ahead to an EHR entry based on thefrequency or number of entries having a similar score that were codedsimilarly in the same class or subclass. Alternatively, the process mayskip EHR entries having relatively similar scores to another set of EHRentries that may be separated by a gap in the queue. Alternatively, anEHR entry may be selected by evaluating the information content ofcandidate documents. For example, a distance may be calculated betweenthe candidate document and the previously selected document or a seriesof previously selected documents. More specifically, such a distance maybe calculated using the document information profile of the documentsand a weighting technique (e.g., nearest neighbor, cosine, Jaccardindex). To avoid overtraining, a document may be selected when thedistance is inside (similar) or outside a boundary (dissimilar).Alternatively, some other techniques used in rule-based or unsupervisedlearning techniques may be used (e.g., clustering, threading). Forexample, documents of the collection may be clustered based upon theirsimilarity and a document may be selected at random from a clusterdifferent from that of the previously selected document or the series ofpreviously selected documents. A document may also be selected by usingreceived user coding decisions. For example, a random document may beselected when a certain percentage of received health care providercoding decisions in a series of health care provider coding decisionshave assigned the same code

In certain embodiments, diversity may be achieved by rotating the EHRentry document selection among a number of different ranking techniques.For example, at one iteration, a document may be selected from theresults returned by a keyword search of the document collection or bycomparing the documents with an exemplary document (e.g., a documentfrom or outside of the collection) provided by the user. At a subsequentiteration, a document may be selected using the results returned by adifferent keyword search of the document collection, according to a rankin a priority queue, or by a comparison with a different exemplarydocument provided by the user. Move-to-front pooling may be onetechnique used to rotate document selection among different rankingtechniques. More specifically, move-to-front pooling prioritizes theranking techniques that are used for document selection. For instance,move-to-front pooling may prioritize rankings techniques that aredetermined by the human reviewer to yield a higher preponderance ofrelevant documents, for example, through analysis of user codingdecisions.

Alternatively, a document may be selected at step 814 (FIG. 15b )according to how closely scores for a document are to one or morecalculated threshold values that are used to classify documents from thedocument collection into classes or subclasses, preferably using acalculated threshold that maximizes a stopping criterion. For example,document selection 814 may select the document closest to the threshold(i.e., through uncertainty sampling).

After selection by an active learning module or a user, the document ora reference to the document, may be transmitted to health care provider1010 for review. The health care provider may review the EHR text entryand code through an interface (e.g., active learning interface 1012). Incertain embodiments, the interface may be a graphical or textual userinterface presented on a display coupled to the classification system.Tightly coupling document selection and presentation (e.g., at the samecomputer) allows the classification system to minimize latency betweenactive learning iterations.

A user or set of users who may be selected by the system to classifydocuments retrieved at step 814 of the active learning process may bespecified by a prior user 1010, for example, during initialization ofthe classification problem or at any later time. Alternatively, a usermay register his or her availability to classify documents with anactive learning module 1160. User 1010 may limit his or heravailability, for example, by specifying a specific classificationproblem, certain document or EHR entry types, a specific document fileextension or time during registration with active learning module 1160.

When a connection is made between active learning module 1160 anddocument review push process 1020, document review push process 1020 maybe brought from the background into an active running state on clientdevice 1020. Document review push process 1020 may receive data fromactive learning module 1160 and present the document and any other data(e.g., background data such as a prior related EHR entries for a samepatient or other exemplary highly scored documents) to the user using anactive learning interface such as interface 1012 of FIG. 10. In someembodiments, the transition from background to foreground processinvolves the presentation of a graphical user interface on the clientdevice 1020. A similar background process technique may be used forpushing documents of an initial document set to user 1010 in order toallow user 1010 to make user coding decisions 555 (FIG. 12c ) for thedocuments of an initial document set.

In some embodiments, active learning module 1160 may send a message touser 1010, indicating that an EHR entry having assigned codes is readyfor review. For example, active learning module 1160 may send a textmessage or email for the document that needs to be reviewed. An activelearning interface may be presented to the user when user 1010 clicks orotherwise activates access to the EHR entry document or attachmentpresented in the message. A similar messaging technique may be used forallowing user 1010 to make user coding decisions 555 for documents in aninitial document set.

In active learning mode, active learning module 1160 is able to receiveuser coding decisions 555 for the EHR entry (e.g., code class 930 orsubclass 940 assigned to the entry). When a user coding decision 555 isreceived from the health care provider 1010, active learning module 1160may update the classifiers using classifier generator 1140.

In some embodiments, instead of waiting for a health care providercoding decision 555 (FIG. 12c ) from a health care provider 1010 (FIG.10), active learning module 1160 (FIG. 11) may fork additional copies ofclassification process 1150 at step 935 (FIG. 9B). These forked copiesrepresent parallel document classification paths. Each forked copy ofclassification process 1150 will represent a prediction of the usercoding decision 555 for the selected document as to a particular classor subclass of the classification problem. Thus, taken as a whole,forked processes represent the entire user decision space for theselected document with regard to all FIGS. 9A & 9B classes 930 andsubclasses 940 of a classification problem. In some embodiments,original classification process 1150 may be terminated or suspendedafter a document is selected.

While running, each forked classification process 950 may maintain localcopies of classification dependent data (e.g., classifiers, priorityqueues, and/or document scores). Local copies of classificationdependent data are considered local to a forked classification process1150 if they are not affected by another forked classification process1150 during the period of time between forking classification process350 and receiving a user coding decision 555, or between forking and theoccurrence of a timeout waiting for user coding decision 555 for thedocument.

Predicted classifiers and other data that maps onto a predicted usercoding decision 555 for the selected document for each forkedclassification process 350 may be generated at step 915 before runningforked classification processes 350. For example, the predictedclassifiers used by each forked classification process 350 will bemodified by classifier generator 940 using the method describedaccording to a predicted user coding decision 555. More specifically,for a two-class classification problem, forked process A may use localpredicted classifiers updated by classifier generator 900 to handle thesituation in which user 1010 may find the selected document relevant(e.g., a member of class 1). Similarly, forked process B may use localpredicted classifiers updated by classifier generator 900 to handle thesituation in which user 1010 may find the predicted classifiers notrelevant to the selected EHR document. Forked process C may use localpredicted classifiers that are not updated (corresponding to a situationwhere the active learning module 1160 potentially does not receive auser coding decision 555 within a specified time period, or the usercoding decision 555 may not indicate whether or not a predicted code wasnot relevant to the selected EHR entry of the document). A similarforking system can be used for classification problems with additionalclasses 930 and/or subclasses 940.

Each forked classification process 350 may, at step 940, classifydocuments from document collection 920 using their own local data copies(e.g., predicted classifiers, priority queues) substantially as if it isthe only classification process that is running.

If a user coding decision 555 is received or a specified time period isexceeded waiting for a user coding decision 555 for the selecteddocument, the active learning module 1160 may, at step 950, terminate orsuspend all forked classification processes 1150 which are inconsistentwith the user coding decision 555.

Global system data may be updated by active learning module 1160 at step960, for example, by copying or changing a pointer or reference toreflect the local data calculated by the forked classification process1150 that matched the (un)received user coding decision 555 for theselected document. In other words, the classification data generated bythe forked process 1150 mapping to the correct prediction for usercoding decision 555 should be identified and propagated forward. After(non)receipt of user coding decision 555, active learning module 1160may start a new classification process 1150, or original classificationprocess 1150 may be restarted. Started or restarted classificationprocess 1150 may use classification data updated during step 814. (FIG.15a .)

In certain embodiments, classification system 900 of FIG. 9A maynominate a classification process 1150 as a master classificationprocess. For example, before active learning module 1160 is executed forthe first time, a classification process 1150 may be created andnominated as the master classification process. During active learning,master classification process 1150 corresponds to the prediction that areceived user coding decision 555 for the selected document will nothave the effect of modifying any classifier for a class 930 or subclass940 or a timeout situation will otherwise occur. During active learning,as explained above, active learning module 1160 will fork otherprocesses that represent a predicted user coding decision 555 for thedocument (i.e., those responses that would require classifier generator1140 to modify or update a classifier) for the document (e.g., relevantor non-relevant). For example, for a two-class classification problem,initially only a master classification process 1150 is running. Afterdocument selection, classification processes A and B are forkedrepresenting user coding decisions 555 for the selected document ofrelevant and non-relevant, respectively. Classification process Aupdates its local classifiers (and other data as needed) to predict thatthe user will classify the EHR document as described in code ABC.Classification process B updates its local classifiers (and other dataas needed) to predict that the user will classify the EHR document underreview as described in class XYZ. Master classification process 1150 andforked processes A and B may run concurrently (on the same CPUcore/processor or on different CPU cores/processors) or serially. If theuser coding decision 555 indicates ABC, process A is promoted to masterclassification process 1150 and its local classification data ispropagated forward. If user coding decision 555 indicates the EHRdocument is subject of code class XYZ, process B is promoted to masterclassification process 1150 and its local classification data ispropagated forward. However, if the user response the EHR document issubject of code different than ABC or XYZ—master classification process1150 remains the same and the classification data calculated by masterclassification process 1150 during concurrent or serial execution withforked processes A and B is propagated forward.

It will be appreciated that although the total number of EHRclassification codes number into the tens of thousands, often theselection can be narrowed down to 1, two or 3 likely relevant codes. Insome embodiments, instead of forking additional classification processes935 of FIG. 9B, active learning module 1160 may fork and maintain localpredicted classification dependent data mapping to each predicted usercoding decision 555. Classification process 1150 is executed seriallyN-times for each document to be classified, where N represents the spaceof all predictions for user coding decision 555. For example, for atwo-class classification problem, data copy A may use predictedclassifiers updated by classifier generator 1140 to handle the situationin which user 1010 may find the selected document relevant (e.g., inclass 1). Data copy B may use predicted classifiers updated byclassifier generator 1140 to handle the situation in which user 1010 mayfind the selected document non-relevant (e.g., in class 2), while datacopy C may be an original classifier for a class or subclass. Whileawaiting user coding decisions 555, the system may continue to classifydocuments, and classification process 1150 is executed using data copy Afor a given document information profile. Thereafter, classificationprocess 1150 is executed using data copy B for the same documentinformation profile, and then classification process 1150 is executedusing data copy C for the same document information profile. The processcan be then be repeated for the next document in the collection whileawaiting user coding decision 555. The processing of data copies may beinterleaved in any manner. For example, classification process 1150 mayuse data copy A to score a number of documents using their correspondingdocument information profiles, then may use data copy C to score anumber of documents using their corresponding document informationprofiles, then use data copy A again before switching to data copy B.Although the order in which the data copies (e.g., A, B, C) areprocessed is unimportant, classification data (e.g., priority queues andscores) generated by each successive run of classification process 1150should be maintained separately as with the other forking methodsdescribed above. As with the other forking methods, after user codingdecision 555 is received or a timeout occurs, the classification datagenerated by the correct prediction for user coding decision 555 shouldbe propagated forward and which may be displayed to the user. As withthe other forking methods, this method can be extended to classificationproblems with any number of classes 930 or subclasses 940.

Active learning module 1160 may, at step 970, determine whether astopping criterion for the active learning process has been met.Determination of whether a stopping criterion is met is discussedfurther below. If a stopping criterion is not met, active learningmodule 1160 may continue back to step 910 and select a further document.If a stopping criterion is met, active learning module 1160 may, at step980, classify the documents in the collection, for example, by comparingcomputed document scores with a threshold calculated during stoppingcriterion determination.

In some embodiments, active learning process 1160 may continue to rununtil all documents in document collection 920 are processed andclassified. In an alternative embodiment, active learning process 1160may stop when a specified or determined number of documents have beenclassified by classification process 1150. In a further alternativeembodiment, active learning process 1160 may stop when classificationprocess 1150 has classified a specified or determined number ofdocuments into a particular class 930 or subclass 940 or a particularset of classes 930 or subclasses 940. In a further alternativeembodiment, active learning mode may stop when a specified number ofuser coding decisions 555 have been received.

With limited processing power or a large enough document collection, itmay be possible for a user to review a document and submit a user codingdecision 555 for the selected document before classification process1150 or forked classification processes 1150 complete scoring andclassifying each document of the collection. In this case, in order toallow real-time interaction with the classification system 900, it wouldbe more efficient to suspend processing of the remainder of the documentcollection, and instead use the newly submitted user coding decision 555along with the new classifiers to be calculated from the newly submitteduser coding decision. In certain embodiments, processing time may beallocated to forked classification processes based upon a confidencevalue associated with the prediction. For example, more processing timemay be allocated to a forked classification process predicting that theselected document is relevant to a particular class or subclass when theselected document has a high score for that class or subclass.

For the above situation, in order to maintain high efficiency, theclassification process 900 or forked classification process 935 mayprocess the documents of the collection in a particular order, which maybe determined at step 930. For example, in this case, each successiveiteration of the active learning process may be operating withincomplete information, meaning that scores and classification decisionsfor all documents of the collection will have not been calculated. Morespecifically, if selection of the next document for active learning maybe based wholly or partly upon the subset of scores calculated by aforked classification process 1150 during an unspecified interval (e.g.,between selecting a document and receiving a user coding decision), itis preferable to allocate processing time to those documents that willprovide meaningful feedback for a subsequent document selection step910. For instance, after or in response to receiving a user codingdecision, a next or further document may be selected using the score orpriority queue data calculated by a forked classification process 935,941 (or forked data copy) corresponding to the received user codingdecision.

For example, classification process 900, 1150 may process documents byorder of rank in one or more priority queues. Alternatively,classification process 1150 may process the documents according to howclosely scores for the document are to one or more calculated thresholdvalues that are used to classify documents from the collection intoclasses 930 or subclasses 940, preferably using a calculated thresholdthat maximizes a stopping criterion. For example, documents may beprocessed from closest to farthest from the threshold (i.e., usinguncertainty sampling). Different processing orders may be used for eachforked classification process 1150 corresponding to predictedclassifier. It will of course be appreciated after reading the aboveparagraphs, that the classification process may utilize the stepsoutlined in FIGS. 9A and 9B.

As a further alternative, classification process 1150 may combine one ormore of these techniques to achieve a hybrid ordering scheme. In someother embodiments, documents are processed in a manner designed tocomplement document selection step 910. For example, if documentselection step 910 will use uncertainty sampling on the next iteration,then classification process 1150 will also process documents accordingto uncertainty sampling. In certain embodiments, only a partial orderingis calculated or provided. For example, a certain number of documentsmay be ordered (e.g., the first 100,000 documents). Alternatively,ordering may stop once a certain cutoff point is reached (e.g., thedocument score is below a certain threshold). As a further alternative,a number of documents may be ordered based upon an expected user reviewtime for the selected document. For example, a review time may beestimated by the length of the selected document or by keeping a runningaverage of intervals between received user coding decisions.

In certain embodiments, the processing order may be implemented as aninput queue which is processed by the one or more forked classificationprocesses. For example, enqueuing a processing order to a forkedclassification process may start or restart a forked classificationprocess, which may continue to run until all elements of the queue areprocessed or the queue is otherwise empty. The input queue may beemptied in any number of ways. For example, processing a document listedin the input queue may remove an item from the input queue. In certainembodiments, an input queue may be emptied upon the receipt of a usercoding decision.

Incomplete score and priority queue data may be augmented by score andpriority queue data from an earlier iteration of active learning inorder to calculate an approximate ranking for the priority queues. Inorder to acquire complete score and priority queue data for alldocuments of the collection, some iterations of active learning module1160 and classification process 1150 may not be suspended when a newuser coding decision 555 is received.

The use of predicted classifiers and forking allows classificationsystem 900 to take advantage of the latency inherent in user review ofthe selected document. Thus, instead of performing calculations afterthe receipt of the user coding decision, forking allows classificationsystem 900 to have at least a set of partial calculations ready by thetime the user coding decision is received. These partial results allowclassification system 900 to select a next document in an interactiveand real-time manner. By allowing real-time interaction with a user 1010through forking, a single user is able to quickly classify largedocument collections (e.g., tens of millions of documents). Furthermore,by cutting off processing with the receipt of new coding decisions, theclassification system is both more efficient and responsive. Moreover, asingle user approach requires less manpower and likely results in anincrease in precision and recall. Precision and recall are increasedgiven that the inconsistencies engendered by multi-user coding decisionsare avoided. Additionally, a further increase in precision and recallcan be achieved because a single user approach allows an expert on thematter to be employed in the classification effort rather than a team ofnovices or other persons unfamiliar with the subject matter.

The product of the Applicant's disclosure is an electronic health carerecord (EHR) that includes the text of the prior clinician's examinationobservations and diagnosis, as well as treatment and treatmentresponses, as well as the results of clinician ordered tests. The testsmay include but are not limited to laboratory blood tests,electrocardiograms, X-rays, CT scans, etc. Further, the EHR is enhancedby incorporation of entries of relevant ACD, CPT or other recognizedcodes associated with the diagnosis, treatment or tests.

A health care provider may be able to rapidly conduct a search of apatient's EHR to gain, in real time, the patient's health history. Thishistory can be obtained via an electronic search and disclosure requestthat (i) identifies the patient, e.g., contains the patient's name, DOB,SSN, etc., (ii) confirms the patient's consent to the disclosure, (iii)identifies the requesting entity, a secure transmission receivingaddress, (iv) any cryptographic security measures such as a public key,and (v) the scope or substance of the of the request, e.g., a textstatement of requested information such a past “injury, laceration,strain, sprain, twist, soreness or swelling of the left knee, or aseries of ACD or CPT codes applicable to the listed types of injury ortrauma. The EHR could be searched for the text “laceration of leftknee”, “left knee strain”, “left knee twist”, etc. or combination ofthese and other text terms. In another embodiment, the EHR can be searchusing ACD, CPT or other codes that pertain to injury of the left knee.In some embodiments, the requesting health care provider may use anexpanded set of codes for an enhanced capture of relevant information.

It will be appreciated that the patient's consent to a request for allor a portion of the EHR may be obtained at the time of the initialsigning of consent to treatment documents. The patient's signature canbe digitally copied.

The health care provider's request can be directed to one or moreidentified entities. Alternatively, the request may be directed tounspecified entities. In yet another embodiment, the request can bedirected to an organization representing numerous health care providers.An example of such an entity could be Greater Houston Healthconnecthttps://www.ghhconnect.org.

EHR Security and Encryption

Referencing FIG. 23, in one embodiment, the health care provider enterspatient ID (e.g., name, DOB, SSN, etc.) 2401 and data(diagnosis/treatment/test data) into the health care provider's device(sometimes referred to as the “user's device”) 2402. This is dataobtained in a patient encounter, e.g., emergency room visit. As morefully described elsewhere, the entry of text by the health care providerpertaining to patient diagnosis, etc., into the user device may promptcodes, e.g., ICD, CPT, etc., being displayed 2403. The health careprovider may enter codes based upon the suggestion of the user device orenter separate codes 2404. The data, optionally appearing on the displayscreen of the user device, may be transmitted from to a server connectedto a network 2406. This first server may be at the health careprovider's office, clinic, hospital, laboratory, etc. Upon direction ofthe health care provider, making a search request from the device, theserver may initiate communication with one or more EHR repositories2405. The data having been entered by the health care provider mayinclude a user ID. The user ID may be transmitted to the EHR repository,along with a previously established password. The step may ensure thatthe search request, containing patient information, is being receivedfrom a proper source. Utilizing this information an EHR repository mayinitiate a search of its records for information pertaining to theidentified patient 2406.

In another embodiment, the patient information may be providedadditional security. The EHR may require that the requesting serverprovide authentication information. This information may comprise acertificate from an independent certification authority, e.g., VeriSign,etc.

In another embodiment, the patient data/search request may be encrypted.This encryption may utilize a private key. In one such embodiment, thefirst server may transmit a public key to the EHR repository. Thispublic key may allow the recipient to decrypt the search requestinformation. It will be appreciated that the search request informationwill include alphanumeric code information that identifies factors ofthe health care provider's assessment or diagnosis of the patient. Asstated above, the alphanumeric code may be selected in conformance of acode protocol such as CPT or ICD, etc. The search request may alsoinclude the text of the health care provider's assessment or diagnosis.The search request may also contain additional code entries as suggestedinformation that should be included in the search. These additionalcodes may have been suggested by the system at the time the health careprovider inputted his/her assessment or diagnosis.

Each EHR repository receiving the search request may electronicallysearch for records pertaining to the identified patient 2406. Eachrepository will further seek to identify information within itselectronic records that pertains to the listed codes of the searchrequest (both codes pertaining to the diagnosis, treatment or test orcodes additional codes that have been listed in the request) 2407. Alsothe search may include text correlated to the text entries that may beincluded in the search request. Again, the health care provider may alsosuggest key words to be searched within the EHR repository informationfor the identified patient. Responsive data is transmitted from the EHRrepository 2408 to the user device of step 2401.

The relevant documents based upon code or text, which may in oneembodiment include test results (images such as MRI or x-rays) areretrieved. The information may be transmitted back to the requestingparty (the health care provider).

In order to assure the health care provider that the informationreceived is from an authentic source and that the information can berelied upon in the treatment of the patient, the system may require thateach responding EHR repository provide certification from a certificateauthority, e.g., VeriSign, etc. Further, the patient's privacy may bemaintained by each EHR repository encrypting the data to be transmittedusing a private key. The certificate furnished to the health careprovider may include a public key that allows the device (or receivingserver) to decrypt the EHR records responsive to the search criteria.

It will be appreciated that the patient's records of relevant pastmedical treatment will now be available to the health care provider,e.g., an emergency room physician. These electronic records will havebeen searched and transmitted with little delay. The transmission ofinformation may avoid duplication of testing or treatment, includingunnecessary costs and expenses.

The apparatus initiating a search of an EHR repository may comprise anelectronic device containing a processor, memory, user interface,display screen and programing. The device allows a health care providerto enter information into the device pertaining to a patient encounter,the device displays the entered information and the device suggestedcodes and code descriptors selected by the device in response to theentered health care provider information. This device is alsoillustrated in FIGS. 3a-3f and 12a -12 b.

The EHR repository will comprise one or more servers in communicationwith a network such as an Internet or local area network (LAN). Theserver memory may contain electronic health records (EHR) received frommultiple health care entities such as physicians, clinics, hospitals,laboratories, etc. The records may have been originally created inelectronic format or may be scanned images of notes created in a patientencounter such as physical examination (perhaps resulting in adiagnosis) or treatment procedure (drug therapy, physical therapy,counseling, surgery, etc.) or testing (radiation, MRI, echocardiogram,blood testing & results, etc.).

The records will contain patient identifying information such as patientname, date of birth, social security number, etc. The records may beannotated with alphanumeric codes derived from one or more codeprotocols such as Current Procedural Terminology (CPT) or InternationalClassification of Diseases (ICD). The coding annotation may haveoccurred as part of the initial recording of information, orsubsequently added in a coding step (perhaps related as part of thehealth care provider's invoicing procedure). In another embodiment, thecoding may occur at the time the data is received and recorded withinthe EHR repository. In another embodiment, the records my later beannotated with the coding. The coding annotation may occur at the EHRrepository by merging patient billing records with the health careinformation, i.e., the records of the patient encounter. In anotherembodiment, the EHR repository may utilize medical coders toelectronically assign the appropriate alphanumeric code(s) to thereceived records.

The health care provider may instruct the device to conduct a search ofthe patient EHR wherein the device communicates information to a remoteserver (i.e., a computer connecting one or more computer accessed EHRrepositories) wherein the information comprises patient identity andalphanumeric codes wherein the codes have been assigned from one or morecode protocols. The search request may also contain word elements ortest classifications, e.g., “INR” for measurement of blood coagulationproperties.

In an embodiment, the search request transmitted to the EHR server willcontain at least one alphanumeric code specific to the patient'sobserved condition or diagnosis. The codes may also be specific totreatment or medical procedures that have performed for the benefit ofthe patient. The codes may also pertain to tests, etc., that have beenconducted for the benefit of the patient in the course of medicaltreatment. These codes will be matched with codes contained in the EHRrecords. The search may include entries related to similar codesutilizing machine learning described in the related applications.

The codes will have been selected from a code protocol (ICD, CPT, etc.)wherein each code describes and pertains to a particular health carecondition or treatment or test, etc. Another coding protocol is theHealthcare Common Procedure Coding System (HCPCS). Yet another protocolis the Diagnostic Related Grouping (DRG) codes.

In an embodiment, the health care provider identity andauthorization/passcodes, identity of the device initiating the searchrequest, and device authorization/authentication information may berequired as part of the search request communication. In one embodiment,the health care provider (requesting party) may utilize apre-established user name and password. In other embodiments, patient'sEHR data may be transmitted to the requesting party (health careprovider) using asymmetric encryption and a “public key infrastructure”(PKI) as discussed below.

Applicant's FIG. 20 illustrates a public key infrastructure. The healthcare provider may transmit the text and selected alphanumeric codes toan EHR repository 2001. To assure the EHR repository that the request isfrom a legitimate/authorized health care provider (and not a phishingtransmission), the request is accompanied by a certificate from anissuing authority (CA) 2003. The search request may be encrypted by aserver in communication with the health care provider's device. Therequest may therefore be transmitted with a public key that will allowthe EHR repository (relying party) to decrypt the search request 2002.Note that the authentication of the certificate subject party (healthcare provider) may be performed by a registration authority (RA) 2004 incommunication with the certificate authority 2003. It will beappreciated that the certificates may be limited for a duration in time.Also certificates can be revoked for reasons such as the health careprovider's security having been compromised. Revoked certificates can betracked by a CLR distribution point 2005. The CLR distribution point maycommunicate to the relying party (EHR repository) 2002 that a profferedcertificate from the subject (health care provider) 2001 has beenrevoked.

FIG. 21 illustrates an additional embodiment of a public keyinfrastructure wherein a segregated and more secure root CA 2107 is usedto issue certificates to the CA 2103. Also a certificate transparencylog 2106 may be in communication with the EHR repository 2102. Further,the CLR distribution point may include an online certificate statusprotocol to expedite the EHR repository's inquiry whether thecertificate proffered by the requesting party 2101 is valid.

It will be appreciated that the EHR repository wants to be assured thatthe request for patient data is being received from an authorizedentity. Conversely, the requesting party wants assurance that thereceived data is valid data from the repository.

In an embodiment, the user device must be authenticated. This mayrequire authentication utilizing the device MAC address and priorassignment of an authentication code. See FIG. 18, item 1809. Note alsothat the step of authenticating the user device of step 1809 may beperformed at the time the request is initially received. See step 1803 &1804. It may require utilization of a Session Initiation Protocol (SIP).

Note that in the above embodiment, the device must also be authorized tosend and receive information to the EHR repository. The device may beidentified from its Media Access Control (MAC) address. The MAC addressmay have been previously recorded as an authorized address fortransmission and receipt of data. There may also need to be initiationof a Session Initiation Protocol (SIP) which may utilize a proxy server.The requestor (health care provider) may also be required to beauthorized 1804. This maybe performed utilizing a user ID and password.It may also be performed utilizing a certificate authority issued by athird party CA. See FIG. 20, item 2003.

In another embodiment, only the requesting party is required to beauthenticated. To maintain the confidentiality of patient EHRs, therequesting party and EHR may utilize asymmetric cryptography with publickey infrastructure and creation of a private key and public key. Thepublic key infrastructure (PKI) may include a certification authority(CA), as well as a registration authority (RA) working with the CA, rootcertificate authority, etc.

It will be appreciated that the certificate (issued by a third party CA)assures the one party (relying party) to an information exchange, e.g.,the health care provider or EHR repository, that the requesting party orEHR repository (subject party) is whom they say that are. Eachcertificate has a unique serial number, may be valid for a defined term,and identifies the certifying authority. Certificates can be cancelledand replaced. Cancelled certificates are identified on a publicCertification Revocation List (CRL). An Online Certificate StatusProtocol (OCSP) may also be utilized. Further the PKI may include acertificate transparency log identifying all of the issued certificates.

In one embodiment, the EHR repository may create a private key andrelated a public key utilizing an algorithm. The private key isconfidential and retained by the EHR repository. The private key will beutilized to encrypt data (portions of the patient's EHR responsive tothe request). The requesting party may have a copy of the public keythat can be utilized to decrypt the EHR data. It will be appreciatedthat the EHR repository's public key may be widely disseminated amonghealth care providers that may seek access to the electronic healthrecords within the repository.

In another embodiment, the public key received from the EHR repositorymay be authenticated utilizing known protocols. The public key may betransmitted with a certificate assuring that the key is from therepository. In this embodiment, the repository may be referred to as the“subject” of the certificate and the requesting party is the “relyingparty”. The authentication will assure the health care providerreceiving the data and decrypted with the received public key is in factfrom the EHR repository. Stated differently, the health care providerwill know that the public key used to decrypt the encrypted patient datais in fact the public key of the EHR repository.

The EHR repository can utilize its private key to encrypt the responsivedata. See FIG. 19, item 1903 & 1904. The EHR repository, i.e., relyingparty, can decrypt the search request with the transmitted public key1905. The EHR repository can search for the existence of recordspertaining to the identified patient 1906 and, if records are located,the records may be searched using the alphanumeric codes containedwithin the search request 1907. The EHR repository can transmit itsresponse along with its own Certificate Authority to the requestingparty and the search results 1908. The requesting party can decrypt theresponse with the EHR repository public key contained with theCertificate Authority. This public key may also be stored on therequesting party's device.

In another embodiment, the user device communicates directly (andsimultaneously) with one or more EHR databases. This would be distinctfrom a wheel and spoke model. In other words, the device is not requiredto communicate with a central clearing house that may comprise thecombined databases of multiple entities, e.g. hospitals, clinics,physician's offices, etc.

The requesting party, i.e., health care provider, will preferably havea 1. pre-established user name and a 2. Passcode. This should constitute2 factor authorization and allow the subject (EHR repository) to trustthe origin of the request, i.e., the request is from a health careprovider requesting patient information for the purpose of medicaltreatment of the patient.

The device used by the requesting party, e.g., a tablet computingdevice, smart phone, desktop CPU, etc., will have an established andunique MAC address. The MAC address will further allow the EHRrepository to trust the validity of the information request. The methodmay also utilize public key infrastructure (PKI).

In a separate embodiment, for each device communicating, i.e.,initiating a search request, with the repository database,authentication or legitimacy of the requesting party may be required bythe repository server. This can be in addition to or in lieu of the username/password combination. In this embodiment, each user would have tobe authorized by the repository of EHR. This could also be in additionto or in lieu of separate authorization of the entity server, e.g. priorauthentication of a MAC address.

In one embodiment, both the device and the user must be authorized.

In an embodiment, there are multiple users, each possessing their ownCPU device, e.g. a tablet device. Multiple tablets could be individuallyconnected a server. The server may be located an entity, medical office,clinic, hospital, laboratory, imaging facility, etc. This “entityserver” may communicate with the EHR repository/database server.

In one embodiment, the entity server would require authorization fromeach user (user name, password, and/or use of a PKI structure). In turnthe server would have to be authenticated to the receiving repository ofthe EHR.

As mentioned above, in another embodiment, each user device wouldcommunicate with one or more repositories.

Upon authentication of the requesting party (and in some circumstances,authentication of the device), the device or entity server transmits thesearch request. Each search request would contain the patient identity,as well as (i) codes, e.g., selected ACD, CPT, etc., codes and (ii)specified search terms. The specific search terms may be specificlaboratory test classification, e.g., INR for blood clotting capability,physical ailment or anatomical parameter, e.g., knee ligament. Thesearch codes would be the codes, e.g. alphanumeric codes correlated tomedical conditions (diagnoses), treatments or tests appearing on thedisplay of the user's device. (The physician can enter the code(s),utilize the suggested codes, or select among the suggested codes for thescope of the search.) The specified terms may be selected from thehealth care provider's diagnosis or treatment notes, etc.

It will be appreciated that there are multiple code protocols. In oneembodiment, the device (used by a health care provider) may containmultiple code protocols. The entry of a draft diagnosis or observedcondition may result in the device displaying not only the text enteredby the health care provider but also alphanumeric codes correlated tothe patient diagnosis, etc., but also the appropriate or suggested codesof several code protocols. This feature will allow all entries withinthe EHR repository to be searched notwithstanding the repositorycontaining entries utilizing or indexed with differing protocols. Thefunction of supplementing codes appearing on the user device in responseto the health care provider's text entries may be performed by a serverin communication with the user device. For example, if the user devicedisplays and transmits codes selected from the ICD-10 protocol, theserver may correlate the ICD-10 code to the counterpart CPT code, etc.Both the ICD-10 and CPT codes will therefore be searched in the recordsof the EHR repository.

For example, text entry of “torn right knee ligament” would, under theICD-10 code provide the following suggested codes:

a. S83.401A Sprain of Unspecified collateral ligament of right knee b.0MQN0ZZ Repair of right knee bursa and Ligament, Open Approach c.0MQN3ZZ Repair right knee bursa and ligament, Percutaneous Approach d.0MQN4ZZ Repair right knee Bursa and ligament, Perc Endo Approach

The CPT protocol would list the following for the same “torn right kneeligament search:

a. 27405 Repair, primary, torn ligament and/or capsule knee: collateralb. 27407 Repair primary torn ligament & Capsule knee Cruciate c. 27409Repair, primary, torn ligament and/or capsule, knee; collateral andcruciate ligaments

The repository would first search its database for an EHR for therelevant/identified patient. If an EHR was not located, a message couldbe communicated to the user device stating that fact. If an EHR waslocated, the repository (server) could optionally search using thecriteria set forth in the search request. If there were anyextra-ordinary information disclosure restrictions (beyond that requiredof HIPAA), the disclosure requirements could be communicated to the userdevice. The health care provider would have to attempt to comply withthe extra-ordinary requirements in order to proceed further.

Note that the system subject of this disclosure does not require thatthe search be of a specific format. The search will identify the patientand the relevant diagnosis/treatment/test codes of the search. Thesearch may also include text entries that may be searched. The combinedcode and text entries will provide enhanced search results.

The repository may require the user device to provide confirmation thatthe requested information is required for treatment of the patient(thereby exempting the disclosure of patient information from anyconsent requirement under HIPAA).

Each physician's office, clinic, hospital and laboratory may createtheir own EHR repository. Preferably, a individual EHR repository may belinked to multiple other repositories. In some embodiments, the interlinked EHR repositories may comprise a distributed network wherein eachrepository maintains a ledger of each entry made to a specific patient'sEHR. This constitutes a block chain of EHR records, thereby ensuring theauthenticity and accuracy of the information within the EHR. Thisdistributed ledger structure may be facilitated by the authenticationand confidentiality procedures utilized in the

Each EHR entry would, of course, identify the patient and the date ofencounter (examination/treatment/test, etc.). In an embodiment, theelectronic entry will contain the notes or observations of the healthcare provider along with suggested or selected billing codes. Similarly,a physician's notes of treatment would also contain the codes suggestedor selected. If the physician's services were invoiced to a third-partypayor or invoiced to the patient wherein billing codes were assigned,the billing codes could be included in the physician's notes. Thesecodes contained in the patient records of the EHR repository may be usedas an index to expeditiously search for information related to thehealth care provider's search request. Again, the search request maycontain codes of multiple code protocols that are relevant to the healthcare provider's diagnosis, etc. Again, it must be remembered that theuser device may automatically suggest billing codes based upon thecontents of the physician's notes (or ordered tests, the test resultscollated with the billing code and order).

In a further embodiment, the EHR repository may include invoicescontaining the codes associated with the invoiced diagnosis/treatment/testing.

Accordingly the preceding discloses a tool such as a tablet computer orsimilar that can record a clinician's notes of patient systems ortreatment responses. The method of utilization of this tool creates anentry into a comprehensive patient electronic health record (EHR). Thetool and method includes correlating the clinician's electronicallyrecorded notes to accepted medical diagnosis and treatment codingprotocols. The disclosure teaches how the tool may facilitate clinicianuse by providing suggest autocompletion of entries. The disclosure alsoteaches how the tool or device can correlate the clinician's entries toaccepted code protocols, including use of the code descriptors. Theclinician may accept suggested diagnostic treatment codes or modify thenotations to prompt a new or modified slate of suggested codes.

The disclosure thereby teaches the integration of the codes into thepatient specific EHR. The disclosure teaches how the EHR may be searchedutilizing the codes to identify EHR entries of relevance and interest.

The EHR records, annotated with a searchable code or index is alsosubject of this disclosure.

The tool of the disclosure may also be utilized for the display ofsearch results, including images such as recorded X-ray images.

The disclosure further teaches the tool and methods requiring entry ofauthentication information for the protection of patient privacy of EHR.These methods include but are not limited to two factor authenticationor private/public key combinations.

This specification is to be construed as illustrative only and is forthe purpose of teaching those skilled in the art the manner of carryingout the disclosure. It is to be understood that the forms of thedisclosure herein shown and described are to be taken as the presentlypreferred embodiments. As already stated, various changes may be made inthe shape, size and arrangement of components of the system or device.Also adjustments made in the steps or order of the steps of the methodwithout departing from the scope of this disclosure. For example,equivalent elements may be substituted for those illustrated anddescribed herein and certain features of the disclosure maybe utilizedindependently of the use of other features, all as would be apparent toone skilled in the art after having the benefit of this description ofthe disclosure.

While specific embodiments have been illustrated and described, numerousmodifications are possible without departing from the spirit of thedisclosure, and the scope of protection is only limited by the scope ofthe accompanying claims.

What I claim are:
 1. A device for electronically entering patientidentification, patient health information and health care provideridentification wherein information regarding patient examination,diagnosis, treatment or testing may be entered and correlated withapplicable codes of a coding protocol comprising: (a) a device having adisplay, a data entry component, a processor and memory componentconfigured to allow a patient information to be entered, received ordisplayed; (b) a communication component to allow the device tocommunicate patient information with a second device; (c) a computerimplemented program to (i) evaluate entered or received data and suggestcompletion of a data in accordance with a program vocabulary; (ii)evaluate entered or received data and suggest alphanumeric code entriesof a medical coding protocol wherein the suggested alphanumeric codeentry is based upon the data; (d) a communication module configured totransmit a patient information and alphanumeric code entry searchrequest to the second device wherein the second device comprises a datastorage component or a network communication with a data repository. 2.The device of claim 1 further configured to allow receipt of informationfrom the second device or network wherein the information is responsiveto a search request.
 3. The device of claim 1 wherein the data entrycomponent is a keyboard.
 4. The device of claim 1 wherein the datareceiver component is a scanner.
 5. The device of claim 1 furthercomprising components for the receipt and comprehension of naturallanguage.
 6. The device of claim 1 further comprising a speaker.
 7. Thedevice of claim 1 wherein the search request can be initiated by atleast one but not more than two keystrokes of the data entry component.8. The device of claim 1 wherein the search request can be initiated byat least one but not more than two detected motions of a user in frontof a motion receptor.
 9. A device for receipt of patient medicalinformation comprising (a) a display (b) data entry component; (c)memory component; (d) data transmission component; (e) computer programwith machine learning capability that allows auto completion orcorrection of data entry; and (f) computer program with machine learningcapability that may suggest one or more medical codes from a medicalcode protocol responsive to data entry.
 10. The device of claim 9wherein the data transmission component can initiate a search of one ormore medical record databases.
 11. The device of claim 9 wherein thecomputer program may adapt data entered as part of a response to asuggested medical code.
 12. The device of claim 11 wherein the devicemay suggest the data in response to separate or subsequent data entry.13. The device of claim 10 wherein the device further comprisesencryption capability to encrypt data submitted as part of a search ofone or more medical record databases.
 14. The device of claim 13 whereinthe encrypted data comprises patient identity.
 15. A method for a healthcare provider to enter and index information based upon examination,diagnosis treatment or testing of a patient's medical conditionutilizing a medical coding protocol and to allow the health careprovider to search for information of the patient related to the medicalcondition comprising the steps: (a) entering or confirming patientidentity information; (b) entering information regarding patient medicalcondition; (c) receiving suggested medical codes responsive to theentered information; (d) accepting or adopting at least one suggestedmedical code; and (e) initiating a search request of electronicallystored medical records wherein the request includes the medical code.16. The method of claim 15 further comprising electronically receivingdata from the electronically stored medical records responsive to thesearch request.
 17. The method of claim 15 further comprising the steps(a) through (e) utilizing a device comprising a display, data entry orreceiver component, memory component, computer program component forsuggesting one or more medical code entries responsive to data entry anda data transmission component.
 18. A method of searching a patientelectronic health records utilizing a portable electronic devicecomprising: (a) entering or confirming patient identity utilizing anelectronic device data entry component, scanner or display screencomponent; (b) entering patient medical information utilizing devicedata entry component; (c) receiving one or more suggested numeric oralpha-numeric codes from a medical code protocol wherein the suggestedcodes are responsive to the entered data of medical information; (d)selecting or adopting at least one suggested code or entering additionalmedical information or alternate codes; and (e) utilizing a component ofthe portable electronic device to initiate a search for patientelectronic health records.
 19. The method of claim 18 further comprisingthe device receiving patient medical information.
 20. A repository ordatabase of patient specific medical records wherein the records includecodes selected from a medical code protocol.
 21. The repository ordatabase of claim 20 wherein the records are electronically searchable.